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

Question

Я плохой человек, если я использую use Test::More qw(no_plan)?

Тест :: Больше POD говорит

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

use Test::More tests => 23;

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

use Test::More qw(no_plan);

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

Итак, у меня есть 3 вопроса:

1. С чем связано требование плана тестирования по умолчанию?
2. Кто-нибудь нашел эту полезную и экономящую время функцию в долгосрочной перспективе?
3. Поддерживают ли подобные тесты другие тестовые наборы для других языков?

Answer 1

По какой причине требуется план тестирования по умолчанию?

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

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

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

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

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

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

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

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

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

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

Была ли эта функция полезна кому-либо в реальном мире?

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

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

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

Answer 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 также позволяет поставить план в конец.

Answer 3

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

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

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

Answer 4

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

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

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

Answer 5

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

Еще один случай, когда полезно четко определить test_plan, - это когда вы выполняете такие тесты:

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

и

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

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

Answer 6

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

• Лучше использовать 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 и других проблем, которые делают план проблемным: Почему числовые планы тестирования плохие, неправильные и на самом деле не помогают в любом случае

Answer 7

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

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

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

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

Answer 8

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

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

Answer 9

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