Зачем мне использовать expect() при написании тестов с помощью QUnit?

Недавно я начал использовать QUnit для модульного тестирования своего JavaScript, и меня немного смущает функция в документации: expect().

Согласно документам, expect() предназначен для:

[s]укажите, сколько утверждений должно выполняться в рамках теста.

И вот пример, который они приводят:

test( "a test", function() {
  expect( 2 );

  function calc( x, operation ) {
    return operation( x );
  }

  var result = calc( 2, function( x ) {
    ok( true, "calc() calls operation function" );
    return x * x;
  });

  equal( result, 4, "2 square equals 4" );
});

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


person Levi Hackwith    schedule 21.02.2013    source источник
comment
Полное предположение от того, кто знает все о QUnit: его можно использовать в качестве защиты от бесконечных циклов. Кажется, что это максимальное ограничение, а не минимальное, поэтому вы можете использовать expect(100) (или аналогичный), и все должно быть в порядке.   -  person Niet the Dark Absol    schedule 21.02.2013
comment
Это неправильно, это не минимум и не максимум, это определяет точное количество утверждений, которые вы ожидаете. Если число ниже или выше ожидаемого, тест не пройден.   -  person Odi    schedule 26.02.2013


Ответы (2)


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

Что ж, я думаю, что expect предназначен для использования с сгруппированными значимыми задачами. Это полезно для тестирования событий или обратных вызовов, например:

test('trigger an event', function() {
  expect(1);

  $('div')
    .on('click', function() { ok(1) });
    .trigger('click');
});

Это не станет кошмаром, если вы сгруппируете значимые задачи в небольшие тесты, где ожидается только 2 или 3 утверждения.

person elclanrs    schedule 21.02.2013
comment
Чтобы уточнить, когда вы тестируете асинхронный код, есть шанс, что асинхронное событие не произойдет, и ваш тест не запустится. В этом случае вам нужен провал, а не молча пропущенный тест. - person adamesque; 18.06.2014

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

person terrarum    schedule 11.03.2014