Почему мне нужно знать, сколько тестов я буду запускать с помощью Test:: More?

Ответ 1

В чем причина стандартного тестирования плана?

ysth ответьте на отличный обсуждение этой проблемы, которая включает комментарии Майклом Шверном и Овидом, которые являются сторонниками Test::More и Test::Most соответственно. По-видимому, это время от времени появляется в списке perl-qa и представляет собой немного спорную проблему. Вот основные моменты:

Причины не использовать план тестирования

• Его раздражает и требует времени.
• Это не стоит того времени, потому что тестовые скрипты не умрут без проверки жгута проводов, за исключением некоторых редких случаев.
• Test::More может рассчитывать тесты по мере их возникновения.
• Если вы используете план тестирования и вам нужно пропустить тесты, у вас возникает дополнительная боль, требующая блока SKIP{}.

Причины использования плана тестирования

• Это займет всего несколько секунд. Если это займет больше времени, ваша тестовая логика слишком сложна.
• Если в коде есть код выхода (0), ваш тест завершится успешно, не выполняя оставшиеся тестовые примеры. Наблюдающий человек может заметить, что вывод на экран не выглядит правильным, но в автоматическом наборе тестов он может остаться незамеченным.
• Разработчик может случайно записать тестовую логику, чтобы некоторые тесты не выполнялись.
• У вас действительно не может быть индикатор выполнения, не зная заранее, сколько тестов будет выполнено. Это сложный, чтобы сделать это только через самоанализ.

Альтернативный

Test::Simple, Test::More и Test::Most имеют done_testing(), который должен вызываться в конце теста script. Это подход, который я принимаю в настоящее время.

Это устраняет проблему, когда код имеет exit(0). Это не устраняет проблему логики, которая непреднамеренно пропускает тесты.

Короче говоря, его безопаснее использовать план, но шансы на это, фактически сохраняя день, низки, если ваши тестовые комплекты не сложны (и они не должны быть сложными).

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

Эта функция была полезной для любого в реальном мире?

Несколько человек отмечают, что эта функция была полезной для них в реальном слове. Сюда входит Ларри Уолл. Майкл Шверн говорит, эта функция возникает у Ларри более 20 лет назад.

У других языков есть эта функция?

Ни один из наборов тестирования типа xUnit не имеет функции плана тестирования. Я не сталкивался с примерами этой функции, используемой на любом другом языке программирования.

Ответ 2

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

Во время разработки я использую no_plan, потому что постоянно добавляю к набору тестов. Когда ситуация стабилизируется, я проверяю количество тестов, которые должны запускаться, и обновлять план. Некоторые люди упоминают, что "тестовая упряжь" уже поймала это, но нет такой вещи, как "тестовая упряжь". Там тот, который большинство модулей использует по умолчанию, потому что это то, что указано в MakeMaker или Module:: Build, но выход TAP не зависит от какого-либо конкретного потребителя TAP.

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

use vars qw( $tests );

BEGIN {
  $tests = ...; # figure it out

  use Test::More tests => $tests;
  }

Вы также можете отделить счетчик от загрузки:

use Test::More;

plan tests => $tests;

Последняя TAP позволяет также поместить план в конец.

Ответ 3

В одном комментарии вы, кажется, думаете, что преждевременное завершение будет считаться провалом, так как план не будет выводиться в конце, но это не так - план будет выводиться, если только вы завершаетесь с POSIX:: _ выходом или фатальным сигналом или тому подобным. В частности, die() и exit() будут в плане вывода (хотя тестовая жгута должна обнаруживать что-либо, кроме выхода (0), как тест с преждевременным прекращением).

Возможно, вам захочется взглянуть на вариант Test:: Most отложенного плана, который вскоре появится в Test:: More (если он еще не был).

В последнее время также обсуждалось это в списке perl-qa. Один поток: http://www.nntp.perl.org/group/perl.qa/2009/03/msg12121.html

Ответ 4

Проведение любого тестирования лучше, чем тестирование, но тестирование - это намеренное. Утверждение ожидаемых числовых тестов дает вам возможность увидеть, есть ли ошибка в тесте script, которая препятствует выполнению теста (или выполняется слишком много раз). Если вы не запускаете тесты в определенных условиях, вы можете использовать функцию пропуска, чтобы объявить это:

  SKIP: {
      skip $why, $how_many if $condition;

      ...normal testing code goes here...
  }

Ответ 5

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

Другим случаем, когда было бы полезно определить test_plan, явным образом, когда вы делаете такие тесты:

$coderef = sub { my $arg = shift; isa_ok $arg, 'MyClass' };
do(@args, $coderef);

и

## hijack our interface to test it called.
local *MyClass::do = $coderef;

Если вы не укажете план, легко пропустить, что ваш тест не прошел, и что некоторые утверждения не выполнялись, как вы ожидали.

Ответ 6

Я нахожу это раздражающим, и обычно я игнорирую номер в самом начале, пока тестовый набор не стабилизируется. Затем я просто обновляю его вручную. Мне нравится идея узнать, сколько полных тестов есть как секундный тик, как своего рода индикатор прогресса.

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

#----- load non-existant record -----
....
#----- add a new record -----
....
#----- load the new record (by name) -----
....
#----- verify the name -----
etc.  

Затем я могу быстро сканировать файл и легко подсчитать тесты, просто ищет строки #-----. Полагаю, я мог бы написать кое-что в Emacs, чтобы сделать это для меня, но это, честно говоря, не так уж тяжело.

Ответ 7

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

• Лучше, чем no_plan использовать done_testing()

  use Test::More;
... run your tests ...;
done_testing( $number_of_tests_run );
# or done_testing() if not number of test is known

• Эта запись в блоге Matt Trout интересна и требует добавления планов против конфликтов cvs и других проблем, которые делают план проблематичным: Почему числовой тест планы плохие, неправильные и фактически не помогают в любом случае

Ответ 8

Это боль при выполнении TDD, потому что вы произвольно пишете новые тесты. Когда я преподавал TDD, а в магазине использовался Perl, мы решили использовать наш набор тестов без плана. Думаю, мы могли бы измениться с no_plan, чтобы заблокировать количество тестов. В то время я видел это скорее препятствием, чем помощью.

Ответ 9

Ответ Эрика Джонсона точно верен. Я просто хотел добавить, что done_testing, гораздо лучшая замена no_plan, недавно была выпущена в Test-Simple 0.87_1. Это экспериментальный релиз, но вы можете скачать его прямо из предыдущей ссылки.

done_testing позволяет объявить количество тестов, которые, по вашему мнению, были запущены в конце тестирования script, вместо того, чтобы пытаться угадать его до запуска script. Вы можете прочитать документацию здесь.