Я написал небольшой Perl script, и теперь я хотел бы создать для него набор тестов. Я подумал, что было бы неплохо иметь возможность use script в качестве модуля, импортировать подсистемы, определенные в script, и протестировать их. Есть ли способ иметь script как автономный Perl script, так и модуль Perl? (Я не хочу разделить script на отдельный модуль и "исполняемый файл", так как я планирую распространять script как один файл.)
Или есть лучший способ проверить script?
Так как Брайан, похоже, сейчас спит, здесь указатель на то, что он называет modulinos. Это в основном рецепт для создания скриптов, которые действуют как модули или модули, которые можно запускать как скрипты. Звучит точно так же, как и вы.
Освоение Perl - это определенно книга, которая стоит читать (и покупать).
(Я не хочу разделить script на отдельный модуль и "исполняемый файл", так как я планирую распространять script как один файл.)
Большинство людей сшивают файлы вместе, как это во время сборки. App:: Ack на CPAN - пример того, что можно построить таким образом.
Если вы действительно хотите правильно протестировать свое приложение, вам нужно поместить функциональность в модуль, а затем написать тест на основе Test:: More script, который выполняет функции, предоставляемые модулем. Тогда фактический script является просто тонкой оболочкой вокруг модуля, обычно что-то вроде:
#!/usr/bin/env perl
use Your::Class;
Your::Class->new(args => \@ARGV)->run;
Смотрите также: MooseX::Getopt.
Я хочу сделать то же самое. Есть ли причина не делать следующее? (Я не эксперт perl, решение, похоже, отлично работает для меня.):
в начале script Я запрашиваю переключатель ( "-test" ) или что-то еще, а не ветку на суб подобную:
my $myargs = CmdLineOptions->new( args=>\@ARGV );
if ($myargs->was_given(option=>"-test")) { &tests; }
sub tests {
require "Test/More.pm";
Test::More->import('no_plan');
is(1,1,"my tests go here");
exit;
}
(с помощью require и import я подавляю сообщение "# no tests run!", которое я получаю при использовании "Use Test:: More" без каких-либо тестов. Думаю, это также снижает накладные расходы.)
Это зависит от того, хотите ли вы протестировать сам script или проверить подсистемы, составляющие script. Если вы хотите протестировать script, тогда внешний тест будет более уместным, например. оболочка script. Если вы хотите протестировать функции, которые составляют script, вы можете либо записать эти тесты как больше функций в script, либо реорганизовать элементы в модуль Perl, и протестировать модуль (который, как вы говорите, хочу сделать).
Если script достаточно мал, то рефакторинг может не понадобиться. Просто добавьте аргумент командной строки '-test' и вызовите тестовый элемент sub, который, в свою очередь, проверяет все остальное. Если я это сделаю, мне нравится распечатывать индикатор прогресса какого-либо типа (например, "." Для каждого пройденного теста).
Если script более сложный, тем не менее, вы можете захотеть рассмотреть рефакторинг битов в один или несколько модулей и протестировать их с помощью Test:: Simple или Test:: More.
Почему бы не написать тестовый пакет в оболочке script с помощью Perl script, называемого любой другой командой оболочки?
Так как я просто хотел протестировать один сабвуфер, я использовал хакерское решение для извлечения этого сабвуфера в модуль с однострочным перл, что легко понять и не требует установки каких-либо модулей (я извлекаю абзац с субабонентом имя которое конечно хрупкое). Итак, в моем Makefile у меня есть:
MyModule.pm: my_script.pl
perl -00 -lnE 'if(/^\s*sub my_sub \{/){say "package MyModule;";say;say "1;";}' my_script.pl >|MyModule.pm