Pull to refresh

Comments 16

Насчёт асинхронных тестов. Они получаются слишком хрупкими и запутанными. Поэтому вместо асинхронных тестов, я сейчас пишу синхронные вида:


  1. Выполнили какое-то действие, предварительно застабив внешние зависимости.
  2. "Промотали" время.
  3. Проверили результат.

Соответственно, ошибки запроса вываливаются на первом шаге. Ошибки обработки ответа — на втором. Ошибки логики — на третьем. Тесты получаются простыми, понятными и быстрыми.

Я считаю что работа с таймерами является наоборот более хрупким решением т.к есть прямая зависимость на время («Промотали» время"), что может привести хоть и к редким но рандомным падениям.

Я ничего не говорил про таймеры :-) И "промотка" не зря в кавычках. Грубо говоря просто дёргается ручка "запустить следующую партию отложенных задач". Соответственно мок XHR в этом случае запустит обработчики ответа на запрос, предоставив им ответ. Мок Promise — следующий обработчик обещания и тд.

Поддерживаю подход с прокруткой времени.
Если замокать все API и таймеры, то тесты действительно получаются простыми, понятными и быстрыми.
Я долго практиковал подход с done(), потом использовал RxJS. В итоге пришёл к простой промотке времени и остался доволен.
И всё это с помощью sinon.useFakeTimers() или что-то другое?

Да мне пока хватает своего велосипеда. Пример теста:


        'wait for data'() {

            class Test extends $mol_object {

                @ $mol_mem()
                source( next? : string , prev? : string ) : string {
                    new $mol_defer( () => {
                        this.source( void 0 , 'Jin' )
                    } )
                    throw new $mol_atom_wait( 'Wait for data!' )
                }

                @ $mol_mem()
                middle() {
                    return this.source()
                }

                @ $mol_mem()
                target() {
                    return this.middle()
                }

            }

            const t = new Test

            $mol_assert_fail( ()=> t.target().valueOf() , $mol_atom_wait )

            $mol_defer.run()

            $mol_assert_equal( t.target() , 'Jin' )
        } ,
А можно попросить вас привести какой-нибудь простой пример?
Тестирование в JS становиться все более распространенной практикой

Я даже не знаю, это хорошо или печально. В плане, печально что только сейчас.

Ваша аргументация неоспорима.)

это перевод статьи 2015 года. Jest тогда еще не был так популярен.


Но, хороший вопрос, зачем переводить такую старую неактуальную статью?

Тем не менее, Jasmine и Mocha сейчас актуально используются во многих проектах, и вопрос миграции с одного на другое вполне актуальный (по своей работе я сейчас с этим столкнулся). Именно по этому я решил перевести данную статья т.к она показывает основную схожость и основные различия API.

Только Tape. Хуже Jasmine с его неконсистентным API вообще ничего нет, даже QUnit был приятнее. А уж эти бесконечные глобалы, из-за которых надо костылить и линтеры, и IDE, брр!

Подскажите, как работает assert для массивов. Внизу пример теста функции, которая разбивает массив на определенное число частей. Функция работает правильно, но тест выдает ошибку. Где косяк?
describe ("breakArray", function() {
	
	describe("Разбиение массива на массивы заданной размерности", function() {
		
		it  ("Разбиение массива на массивы по 2 бит", function() {
			assert.equal( breakArray([1, 2, 3, 4], 2), [[1, 2], [3, 4]] );
		});
	});
	
});
		


image
для массивов и объектов нужно использовать assert.deepEqual
Sign up to leave a comment.

Articles