Какова предпочтительная среда модульного тестирования для Perl?

Question

Я новичок в Perl, и мне интересно, есть ли предпочтительная среда модульного тестирования?

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

Answer 1

Perl имеет МАССИВНЫЙ набор отличных инструментов тестирования, которые идут с ним! Ядро Perl имеет несколько десятков тысяч автоматических проверок, и по большей части все они используют эти стандартные платформы Perl. Все они связаны друг с другом с помощью TAP - протокола Test Anything .

.

Стандартным способом создания TAP-тестов в Perl является использование семейства пакетов Test :: More , включая Test :: Simple для начала работы. Вот быстрый пример:

use 5.012;
use warnings;

use Test::More tests => 3;

my $foo = 5;
my $bar = 6;

ok $foo == 5, 'Foo was assigned 5.';
ok $bar == 6, 'Bar was assigned 6.';
ok $foo + $bar == 11, 'Addition works correctly.';

И результат будет:

ok 1 - Foo was assigned 5.
ok 2 - Bar was assigned 6.
ok 3 - Addition works correctly.

По сути, для начала все, что вам нужно сделать, - это передать логическое значение и строку, объясняющую, что должно произойти!

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

Кроме того, как указал Schwern , почти все современные Test:: модули работают вместе. Это означает, что вы можете использовать Test::Class (как указано Markus ) со всеми замечательными модулями, перечисленными в rjh * answer . Фактически, потому что Test :: Builder - инструмент, на котором Test::More и другие основаны (и в настоящее время поддерживается Шверном ... спасибо Шверну!) - вы можете, при необходимости, построить свой СОБСТВЕННЫЕ подпрограммы тестирования с нуля, которые будут работать со всеми остальными тестовыми средами. Это само по себе делает систему TAP в Perl одной из самых хороших, на мой взгляд: все работает вместе, все используют один и тот же инструмент, и вы можете добавить к фреймворку в соответствии с вашими потребностями с минимальной дополнительной работой.

Answer 2

Самый популярный тестовый фреймворк Perl - это формат результатов теста, известный как TAP (Test Anything Protocol), представляющий собой набор строк, которые выглядят следующим образом:

ok 1 - Imported correctly
ok 2 - foo() takes two arguments
not ok 3 - foo() throws an error if passed no arguments

Любой скрипт, который может генерировать эти строки, рассчитываеткак тест Perl.Вы можете использовать Test :: More для генерации TAP для различных условий - проверка, равна ли переменная значению, проверка правильности импорта модуля или идентичности двух структур (массивов / хэшей).Но в истинном духе Perl есть несколько способов сделать это, и есть другие подходы (например, Test :: Class , который немного похож на JUnit!)

Простой примерсценария тестирования (обычно они заканчиваются на .t, например foo.t)

use strict;
use warnings;
use Test::More tests => 3;  # Tell Test::More you intend to do 3 tests

my $foo = 3;
ok(defined $foo, 'foo is defined');
is($foo, 3, 'foo is 3');
$foo++;
is($foo, 4, 'incremented foo');

Вы можете использовать Test :: Harness (обычно вызывается как prove из оболочки) выполнить серию последовательных тестов и получить сводку пройденных или неудачных тестов.

Test :: More также может выполнять более сложные операции, например помечать тесты как TODO (не ожидайте их)чтобы пройти, но запустите их на всякий случай) или SKIP (эти тесты не работают / необязательно, не запускайте их).Вы можете указать количество тестов, которые вы ожидаете выполнить, поэтому, если ваш тестовый скрипт умирает наполовину, это может быть обнаружено.

Как только вы начнете проводить более сложное тестирование, вы можете найти некоторые другие модули CPAN полезными.- вот несколько примеров, но есть еще много ( много ):

Test :: Exception - проверить, что ваш код выдает ошибку / нетвыбросить любые ошибки
Test :: Warn - проверить, что ваш код генерирует / не генерирует предупреждения
Test :: Deep - глубоко сравнить объекты.Они не должны быть идентичными - вы можете игнорировать упорядочение массива, использовать регулярные выражения, игнорировать классы объектов и т. Д.
Test :: Pod - убедитесь, что в вашем скрипте есть POD (документация) и чтоэто действительно
Test :: Pod :: Coverage - убедитесь, что ваш POD документирует все методы / функции в ваших модулях
Test :: DBUnit - тестовая база данныхвзаимодействия
Test :: MockObject - создает притворные объекты для управления средой ваших тестов

Answer 3

Если вы практикуете TDD, вы заметите, что ваш набор модульных тестов меняет A LOT. Test :: Class следует шаблонам xUnit (http://en.wikipedia.org/wiki/XUnit).

Для меня главным преимуществом xUnit является инкапсуляция каждого теста в методах. Фреймворк называет каждое утверждение именем метода теста и добавляет возможность запускать методы настройки и завершения до и после каждого теста.

Я также попробовал способ "perl-ish" для модульного тестирования (просто используя Test :: More), но я считаю его старомодным и громоздким.

Answer 4

Определенно начните с этой страницы: http://perldoc.perl.org/Test/Simple.html и следуйте ссылке на Test :: Tutorial .

Answer 5

Некоторые антирекомендующие могут быть в порядке:

Anti-рекомендация:

НЕ используйте семейство тестовых пакетов Test::Unit для Perl , таких как Test::Unit::Assert и Test::Unit::TestCases.

Причина: Test::Unit представляется заброшенным.

Test :: Unit, Test :: Unit :: TestCases, Test :: Unit :: Assert работают, довольно хорошо (когда я их использовал 2015-2016). Test :: Unit предположительно не интегрирован с протоколом Perl Test Anything Protocol (TAP), хотя я обнаружил, что это легко исправить.

Но Test :: Unit разочаровывает, потому что многие другие тестовые пакеты Perl, в основном построенные с использованием Test :: Builder, такие как Test :: More, Test :: Most, Test :: Exception, Test :: Differences, Test :: Deep, Test :: Warn и т. Д. НЕ взаимодействуют с подходом объектно-ориентированного тестирования Test :: Unit.

Вы можете смешивать Test :: Unit тесты и Test :: Builder тесты, как только вы адаптировали Test :: Unit для работы с Test :: More и TAP; но хорошие возможности этих других пакетов недоступны для расширения OO. Что во многом является причиной использования теста в стиле xUnit.

Предположительно, CPAN Test::Class позволяет "легко создавать тестовые классы в стиле xUnit / JUnit" - но я не уверен, что могу рекомендовать это. Это, конечно, не похоже на xUnit для меня - не на ОО, это уникальные имена, такие как is(VAL1,VAL2,TESTNAME) вместо имен в стиле xUnit, такие как $test_object->assert_equals(VAL1,VAL2,TEST_ERR_MSG). Test :: Class обладает приятной функцией автоматического определения всех аннотированных тестов: Test, сравнимый с xUnit и подходом TEST :: Unit :: TestCase, использующим интроспекцию для запуска всех функций с именем test _ *.

Тем не менее, базовый пакет Test::Builder является объектно-ориентированным и, следовательно, имеет гораздо больший стиль xUnit. Не пугайтесь названия - это не фабрика, это в основном набор тестовых методов. Хотя большинство людей наследуют его, вы можете позвонить напрямую, например, если хотите. $test_object->is(VAL1,VAL2,TESTNAME), и часто вы можете использовать вызовы Test :: Builder, чтобы обойти ограничения процедурных пакетов, таких как Test :: More, которые построены поверх Test :: Builder - как исправление уровня стека вызовов, при котором сообщается об ошибке.

Test :: Builder обычно используется в одноэлементном стиле, но вы можете создавать несколько объектов. Я не уверен, ведут ли они себя так, как можно было бы ожидать от теста семейства xUnit.

Пока что нет простого способа обойти ограничения, такие как Perl TAP-тесты, использующие TEST_NAMES для каждого утверждения, без иерархии и без различия TEST_NAMES от TEST_ERROR_MESSAGES. (Ошибочный уровень отчетности помогает с этим недостатком.)

Может быть возможно создать адаптер, который делает тесты в стиле Test :: Builder и TAP более объектно-ориентированными, так что вы можете перебазировать что-то отличное от TAP (которое записывает больше полезной информации, чем TAP - предположительно, как протокол ANT XML) , Я думаю, что для адаптации имен и / или отсутствующих понятий потребуется либо перейти в Test :: Builder, либо провести самоанализ.