Существуют ли соглашения об именах функций при использовании Perl Test::More?
-
09-06-2019 - |
Вопрос
Существуют ли соглашения об именах функций при использовании модулей Perl Test::More или Test::Simple?
Я специально спрашиваю об именах функций, которые используются для настройки тестовой среды перед тестом и для разрушения среды после успешного завершения тестов.
ваше здоровье,
Роб
Решение
Я не думаю, что существуют какие-либо подобные соглашения.
Единственный способ сделать это — возможно, использовать блоки BEGIN/END, если ресурсы должны использоваться по всему файлу.
Общий подход, который я использую, заключается в том, чтобы поместить связанные тесты в один блок кода, а затем инициализировать там переменные/ресурс и т. д.Возможно, вы сможете легко подсчитать, сколько тестов у вас есть для каждой функции.
Что-то вроде ...
BEGIN {
# If you want to set some global db setting/file setting/INC changes etc
}
# Tests functionality 1...
{
# have fun ....
}
# Tests functionality 2...
{
# have more fun ....
}
END {
# Clean up the BEGIN changes
}
С другой стороны, вы можете прочитать это для тестирования на Perl... http://perlandmac.blogspot.com/2007/08/using-perl-testsimple-and-testmore.html
Другие советы
Если вам нужны дополнительные сведения о тестировании в стиле XUnit, см. Тест::Класс.Он обеспечивает Test(setup)
и Test(teardown)
атрибуты для методов, которые настраивают и разрушают вашу среду.Это также дает вам гораздо более удобный способ работы с планами (вы можете предоставить по одному плану для каждого метода тестирования индивидуально, поэтому подсчет будет гораздо менее утомительным) и позволяет наследовать тесты через иерархии классов тестов.
Я не думаю, что существует официальный набор соглашений, поэтому я бы рекомендовал посмотреть примеры на http://perldoc.perl.org/Test/More.html и посмотреть, как они пишут свои тесты.
Мы широко используем Test::More для наших модульных тестов, поскольку многие (большинство) наших сценариев обработки данных написаны на Perl.У нас нет определенного соглашения об именах функций, мы делаем что-то вроде того, что предлагает Джагмаль, а именно разбиваем тесты на более мелкие фрагменты и инициализируем их локально.
В нашем случае каждый подтест инкапсулирован в отдельную функцию внутри тестового сценария.Кроме того, у нас есть структура, которая позволяет нам запускать все подтесты (полный модульный тест) или вызывать отдельные подтесты или наборы подтестов, чтобы можно было запускать только те, над которыми мы работаем в данный момент.
Спасибо, Эспо.
Я просмотрел соответствующую документацию perldoc, но не существует единого мнения относительно аспектов установки и демонтажа.
Не похоже на серию тестов XUnit.
Спасибо за ответ, Джагмал, но я не уверен, что можно использовать блоки BEGIN и END для настройки и удаления, поскольку вы не поясняете, что делаете, по именам.Существует также очевидная проблема, заключающаяся в том, что для каждого теста требуется только один запуск установки и один запуск демонтажа, т.е.за каждый файл .t.
Я бегло взглянул на Test::Most, и он выглядит очень интересно, особенно функция объяснения.Спасибо, Мэтт.
Хм.Просто подумывая об использовании блоков BEGIN и END, я думаю, что если я уменьшу детализацию тестов так, чтобы требовалась только одна настройка и одно удаление, то это было бы хорошим решением.
ваше здоровье,
Роб
Первое соглашение, которое я бы предложил, — это отказаться от Test::More for Test::Most.
Скрипты тестирования Perl не являются чем-то особенным или волшебным.Таким образом, они могут содержать то же самое, что и любой другой сценарий Perl.
Вы можете называть подпрограммы как угодно и вызывать их до, после и в сочетании с тестами.
Вы можете иметь любое количество кода инициализации перед любыми тестами, любое количество кода очистки после тестов и любое количество любого другого кода, смешанного с тестами.
Все это предполагает, что вы говорите о тестовых сценариях t/*.t в стиле CPAN.Я так думаю, но я смогу прочитать ваш вопрос как вопрос о удлинении тестовых жгутов, если правильно прищурюсь.
Если вы также готовы принять участие в приемочном тестировании, например, Ruby’s Cucumber — взгляните на этот небольшой пример. http://github.com/kesor/p5-cucumber то есть использование Test::More и огуречного стиля приемочного тестирования.