Статьи

Расширенные концепции QUnit: модули и конфигурация

В последние недели я рассмотрел несколько функций QUnit в руководствах Начало работы с QUnit и Как протестировать асинхронный код в QUnit . Я описал, как настроить среду тестирования QUnit для начала тестирования вашего JavaScript-проекта, что такое утверждение, какие методы предоставляет QUnit и как создавать тесты для синхронного или асинхронного кода.

В этой статье я расскажу, как вы можете организовать свой тестовый код в модулях, и как вы можете настроить QUnit, чтобы лучше соответствовать вашим потребностям, используя свойства конфигурации, предоставляемые платформой.

Организация QUnit в модулях

Возможность организации проекта в более мелкие, более управляемые части не является новой концепцией в разработке программного обеспечения. Разработчики всегда стремились сделать свой код простым и организованным, разбивая кодовую базу на несколько файлов или модулей. Тестирование ничем не отличается. Организация наших тестов в нескольких модулях, особенно если мы пишем тесты для большого проекта, очень полезна и обычно повышает удобство сопровождения.

QUnit предоставляет метод с именем QUnit.module() который позволяет группировать наши тесты в модули. Подпись этого метода показана ниже:

 QUnit.module(name[, lifecycle]) 

Параметр name — это строка, используемая для идентификации модуля, а lifecycle — это объект, содержащий две необязательные функции, которые запускаются до ( настройка ) и после ( разбор ) каждого теста.

Чтобы указать, какие тесты принадлежат данному модулю, вам не нужно выполнять какое-либо обертывание тестов следующим образом:

 // No, it's not like that! QUnit.module('My first module, { setup: function() {}, teardown: function() {}, tests: function() { // Tests here } }); 

Тест принадлежит данному модулю просто, если он определен после вызова QUnit.module() но до того, как будет QUnit.module() другой вызов QUnit.module() . В следующем примере у нас есть тесты, названные «Test 1» и «Test 2», которые принадлежат модулю «Module 1», и другой тест, «Test 3», который принадлежит «Module 2».

 // It's like that and that's the way it is QUnit.module('Module 1'); QUnit.test('Test 1', function(assert) { // assertions here }); QUnit.test('Test 2', function(assert) { // assertions here }) QUnit.module('Module 2'); QUnit.test('Test 3', function(assert) { // assertions here }); 

В идеале имена модулей выражают изолированную часть вашего проекта. Например, библиотека jQuery имеет следующие модули: ajax , core , css , event , selector и т. Д.

Теперь, когда у вас есть четкое представление о том, как тесты группируются в модулях, давайте узнаем больше о функциях setup и teardown . Допустим, вы хотите запустить несколько тестов для следующего объекта:

 var myObj = { name: , items: [] }; 

Вы хотите быть уверены, что перед выполнением теста свойство items будет заполнено числовыми значениями 1 , 2 и 3 . Кроме того, вы хотите, чтобы каждый раз, когда тест завершался, любое дополнительное свойство, которое не является name или items , удалялось из объекта. Такой цели можно достичь с помощью следующего кода:

 QUnit.module('My module', { setup: function() { myObj.items = [1, 2, 3]; }, teardown: function() { for (var prop in myObj) { if (prop !== 'name' && prop !== 'items') { delete myObj[prop]; } } } }); QUnit.test('Test 1', function(assert) { expect(2); // Set a new property of the myObj object myObj.color = 'red'; assert.strictEqual(myObj.items.length, 3, 'The setup function has pushed 3 elements'); assert.strictEqual(myObj.items, [1, 2, 3], 'The setup function has pushed the expected elements'); }); QUnit.test('Test 2', function(assert) { expect(1); assert.ok(!myObj.color, 'The teardown function removed the color property'); }); 

Демонстрационная версия этого примера показана ниже и также доступна в виде JSfiddle .

Теперь давайте посмотрим, как мы можем создать пользовательскую конфигурацию в QUnit.

Как настроить QUnit

Платформа QUnit предоставляет множество свойств конфигурации, которые мы можем изменить, чтобы лучше соответствовать потребностям нашего проекта. Каркас предлагает конфигурацию по умолчанию, подходящую для большинства случаев, но мы можем настроить ее, обновив свойство QUnit.config . Это свойство является объектом, содержащим следующие свойства (сообщается в алфавитном порядке):

  • altertitle : логическое значение, чтобы включить ( true ) или отключить ( false ) QUnit для обновления заголовка тестовой страницы, добавив галочку или «x», чтобы указать, прошел ли тестовый набор или не прошел. Значением по умолчанию является true .
  • autostart : логическое значение, которое, если установлено в false , указывает, что вы хотите запускать тесты самостоятельно, вызывая QUnit.start() а не при QUnit.start() события load. Значением по умолчанию является true .
  • hidepassed : логическое значение, указывающее, должны ли пройденные тесты быть скрытыми ( true ) или нет ( false ). Значением по умолчанию является false .
  • module : строка, которая определяет один модуль для запуска. Значение по умолчанию не undefined , поэтому QUnit запускает все определенные модули.
  • reorder : логическое значение, указывающее, должен ли QUnit запускать тесты, которые вначале не выполнялись при предыдущем выполнении ( true ) или нет ( false ). Значением по умолчанию является true .
  • requireExpects : Логическое значение, указывающее, хотите ли вы принудительно вызывать requireExpects expect() в каждом определенном тесте ( true ) или нет ( false ). Значением по умолчанию является true .
  • testNumber : массив для запуска определенных тестовых блоков по их номеру заказа. Порядок устанавливается при загрузке тестовых блоков. Значение по умолчанию не undefined .
  • testTimeout : число, указывающее максимальное время выполнения, после которого все тесты не пройдут. Значение по умолчанию не undefined .
  • scrolltop : логическое значение, указывающее, хотите ли вы, чтобы QUnits переходил в верхнюю часть страницы при выполнении всех тестов ( true ) или нет ( false ). Значением по умолчанию является true .
  • urlConfig : Массив, который управляет элементами управления формы для размещения на панели инструментов QUnit. Расширяя этот массив, вы можете добавлять свои собственные флажки и выбирать списки.

Теперь, когда вы знаете, какие функции вы можете изменить, давайте посмотрим, как мы можем их использовать. Но сначала важно помнить, что пользовательская конфигурация должна быть написана после включения файла JavaScript в QUnit, но до того, как вы определите тесты.

Допустим, вы хотите заставить тестировщиков в вашей команде всегда определять количество выполняемых утверждений. Вы также хотите, чтобы QUnit скрывал пройденные тесты, потому что набор тестов очень большой. Наконец, вы хотите остановить автоматическую прокрутку QUnit вверх страницы. В этом случае вы можете написать:

 <script src="qunit-1.15.0.js"></script> <script> QUnit.config.hidepassed = true; QUnit.config.requireExpects = true; QUnit.config.scrolltop = true; </script> <script> QUnit.test('My test', function(assert) { // assertions go here... }); </script> 

В этом примере мы увидели базовую пользовательскую конфигурацию. Вы можете расширить его и создать очень сложный, который подходит для вашего проекта.

Вывод

В этой статье я познакомил вас с модулями в QUnit и показал, как создать пользовательскую конфигурацию. В первом разделе мы обсудили, как создать модуль в QUnit, используя метод QUnit.module() , и узнали, как фреймворк группирует тесты вместе. Затем я описал, как создавать настройки и функции разрыва, которые запускаются до и после каждого теста в модуле. Во втором разделе я перечислил все свойства, предоставляемые QUnit, чтобы изменить его конфигурацию по умолчанию, чтобы лучше соответствовать потребностям вашего проекта.

Я надеюсь, вам понравился этот урок. Благодаря этому и моим предыдущим статьям вы теперь можете начать тестировать свои проекты на основе JavaScript с помощью QUnit.