Jasmine vs. Mocha, Chai и Sinon

[vintage]

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

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

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

[VladimirZaets]

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

[vintage]

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

[Vadem]

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

[8gen]

И всё это с помощью sinon.useFakeTimers() или что-то другое?

[vintage]

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

        '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' )
        } ,

[Sutar]

А можно попросить вас привести какой-нибудь простой пример?

[SirEdvin]

Тестирование в JS становиться все более распространенной практикой

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

[miraage]

А про Jest, судя по всему, люди даже не слышали.

[DmitryOlkhovoi]

А Jest просто дешевые понты :)

[miraage]

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

[justboris]

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

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

[VladimirZaets]

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

[k12th]

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

[vladi_gurulev]

Подскажите, как работает assert для массивов. Внизу пример теста функции, которая разбивает массив на определенное число частей. Функция работает правильно, но тест выдает ошибку. Где косяк?

describe ("breakArray", function() {
	
	describe("Разбиение массива на массивы заданной размерности", function() {
		
		it  ("Разбиение массива на массивы по 2 бит", function() {
			assert.equal( breakArray([1, 2, 3, 4], 2), [[1, 2], [3, 4]] );
		});
	});
	
});
		

[qtuz]

для массивов и объектов нужно использовать assert.deepEqual