Тестирование является неотъемлемой частью рабочего процесса каждого разработчика, или, по крайней мере, так и должно быть. Опрос, проведенный несколько лет назад, показал, что около 50% разработчиков JavaScript вообще не пишут тесты, что немного пугает. Несколько месяцев назад я пытался поощрять практику тестирования на JavaScript с помощью серии из трех частей о QUnit , инфраструктуре модульного тестирования JavaScript. Если вы пропустили его, эта серия статей посвящена статьям « Начало работы с QUnit» , « Как протестировать асинхронный код с помощью расширенных концепций QUnit и QUnit: модули и конфигурация» .
В декабре была выпущена версия 1.16 этого фреймворка с некоторыми важными изменениями. В этой статье я познакомлю вас с ними и опишу, как они могут повлиять на ваши тесты.
Подготовка к версии 2.0
Обновление ваших тестов до версии 1.16 теперь поможет вам в процессе перехода на версию 2.0. QUnit 1.16 представляет несколько новых методов, которые станут стандартными на следующем этапе, поэтому планирование теперь является разумным способом подготовки к основному выпуску. Кроме того, как мы увидим через несколько минут, в версии 1.16 пара методов, которые вы использовали для тестирования асинхронного кода, устарела, а некоторые свойства переименованы, поэтому вы должны знать об изменениях.
Новый способ тестирования асинхронного кода
До версии 1.15 для тестирования асинхронной функции вы обычно использовали другой метод для определения теста с именем QUnit.asyncTest()
QUnit.start()
QUnit.stop()
Например, предположим, что у вас есть функция max()
QUnit.asyncTest('max', function (assert) {
expect(2);
QUnit.stop(1);
window.setTimeout(function() {
assert.strictEqual(max(), -Infinity, 'No parameters');
QUnit.start();
}, 0);
window.setTimeout(function() {
assert.strictEqual(max(3, 1, 2), 3, 'All positive numbers');
QUnit.start();
}, 0);
});
Начиная с версии 1.16, QUnit.asyncTest()
QUnit.start()
QUnit.stop()
Чтобы определить асинхронный тест, вы можете использовать тот же QUnit.test()
Механизм запуска / остановки был заменен новым, в котором используется новый метод утверждения async
. Последний возвращает уникальный обратный вызов разрешения каждый раз, когда вызывается, и этот обратный вызов должен быть выполнен в асинхронной операции вместо QUnit.start()
Обратный вызов, возвращаемый QUnit.async()
Перезапись предыдущего теста в соответствии с новым механизмом приводит к следующему коду:
QUnit.test('max', function (assert) {
expect(2);
var done1 = assert.async();
window.setTimeout(function() {
assert.strictEqual(max(), -Infinity, 'No parameters');
done1();
}, 0);
var done2 = assert.async();
window.setTimeout(function() {
assert.strictEqual(max(3, 1, 2), 3, 'All positive numbers');
done2();
}, 0);
});
Вы можете увидеть последний фрагмент в действии ниже, и его код также доступен как JSFiddle :
Поддержка обещаний
QUnit.test()
Обещание — это интересная модель, которая в последние несколько лет широко использовалась как способ заменить обратные вызовы и избежать того, что известно как ад обратного вызова . Обещания были введены изначально в ECMAScript 6, и браузеры начинают реализовывать эту функцию. Если вам нужно введение в обещание, вы можете прочитать статью Обещания JavaScript — туда и обратно .
Возвращаясь к изменению, внесенному в QUnit 1.16, если вы вернете обещаемое Promise в результате выполнения функции обратного вызова, QUnit будет ожидать разрешения или отклонения теста. Пример этой новой функции, взятой из соответствующей страницы официальной документации , представлен ниже:
then
Новый метод: QUnit.test( "a Promise-returning test", function( assert ) {
assert.expect( 0 );
var thenable = new Promise(function( resolve, reject ) {
setTimeout(function() {
resolve( "result" );
}, 500 );
});
return thenable;
});
assert.expect( 0 );
var thenable = new Promise(function( resolve, reject ) {
setTimeout(function() {
resolve( "result" );
}, 500 );
});
return thenable;
});
В дополнение к QUnit.skip()
QUnit.async()
Его можно использовать для определения тестов, которые вы хотите временно отключить и которые не должны выполняться. Чтобы пропустить тест, вы можете заменить вызов QUnit.skip()
QUnit.test()
Итак, допустим, у вас есть тест:
QUnit.skip()
Вы можете заменить вызов QUnit.test('test', function(assert) {
// code goes here
});QUnit.test()
QUnit.skip()
Это простое изменение позволяет вам не комментировать все тесты. Пропущенный тест по-прежнему отображается в репортере HTML, но помечен как «Пропущенный».
Новые свойства для определения функций настройки и удаления
QUnit позволяет организовывать наши тесты, разбивая код на несколько модулей, что особенно полезно, если мы пишем тесты для большого проекта, поскольку это повышает его удобство сопровождения. Для этого платформа предоставляет метод с именем QUnit.skip('test', function(assert) {
Этот метод имеет второй параметр, называемый в документации
// code goes here
});QUnit.module()
Это объект, который может содержать две необязательные функции для запуска до, lifecycle
setup
Например, вы можете определить модуль, как указано ниже:
teardown
В версии 1.16 эти два свойства устарели и заменены двумя эквивалентными свойствами с именами QUnit.module('My module, {
setup: function() {},
teardown: function() {}
});beforeEach
Итак, начиная с этой версии вы должны определить модуль как:
afterEach
Это изменение имеет смысл, поскольку функции на самом деле выполняются до и после каждого теста, а не до и после каждого модуля, как это могут указывать оригинальные имена.
Другие изменения
QUnit теперь совместим с Rhino при QUnit.module('My module, {
beforeEach: function() {},
afterEach: function() {}
});-require
Каркас ищет объект exports
В статье QUNIT Advanced Concepts: Модули и конфигурация я рассмотрел все доступные варианты. В новой версии QUnit свойство module
moduleFilter
При нажатии на ссылку «Rerun» для одного теста теперь используется хеш имени теста для ссылки на тест, называемый testId
testNumber
Это изменение гарантирует, что даже если порядок тестов изменится, QUnit перезапустит тот же выбранный тест.
Выводы
В этой краткой статье вы узнали о новых функциях и изменениях, внесенных в QUnit 1.16. Если вы хотите узнать больше, вы можете взглянуть на список изменений . Обновление вашего теста до этой версии не должно быть очень трудным, но, очевидно, это также зависит от количества тестов, которые есть у вашего проекта.
Что вы думаете об изменениях? Вы используете QUnit для тестирования своих проектов? о чем ты думаешь? Давайте начнем обсуждение.