Существуют ли соглашения об именах функций при использовании Perl Test :: More?

Я не думаю, что существует официальный набор соглашений, поэтому я бы рекомендовал взглянуть на примеры на http://perldoc.perl.org/Test/More.html и посмотреть, как они пишут свои тесты.

Спасибо, Эспо.

Я просмотрел соответствующие perldocs, но нет никакого реального соглашения относительно аспектов установки и разборки.

В отличие от серии тестов XUnit.

Спасибо за ответ, Джагмал, но я не уверен в использовании блоков BEGIN и END для настройки и разборки, поскольку вы не даете понять, что вы делаете, по именам. Также существует очевидная проблема, заключающаяся в том, что для каждого теста требуется только один запуск установки и один запуск разборки, то есть для каждого файла .t.

Я бегло просмотрел Test :: Most, и он выглядит действительно интересно, особенно функция объяснения. Спасибо, Мэтт.

Хм. Просто подумав об использовании блоков BEGIN и END, я думаю, что если я уменьшу степень детализации тестов так, чтобы требовалась только одна настройка и один разбор, то это было бы хорошим решением.

ваше здоровье,

Роб

Я не думаю, что существуют какие-либо подобные соглашения.

Единственный способ сделать это - возможно, использовать блоки 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

Мы используем Test :: более широко для наших модульных тестов, поскольку многие (большинство) наших сценариев обработки данных написаны на Perl. У нас нет конкретного соглашения для имен функций, но мы делаем что-то вроде того, что предлагает Джагмал, а именно разбиваем тесты на более мелкие части и инициализируем локально.

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

Первое соглашение, которое я предлагаю, - отказаться от Test :: More для Test :: Most.

Скрипты тестирования Perl не являются чем-то особенным или волшебным. По сути, они могут содержать те же вещи, что и любой другой скрипт Perl.

Вы можете давать подпрограммам все, что захотите, и вызывать их до, после и одновременно с вашими тестами.

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

Все это предполагает, что вы говорите о тестовых скриптах t / *. T в стиле CPAN. Я думаю, что да, но мне удастся прочитать ваш вопрос как вопрос о расширении испытательных жгутов, если я прищурился.

Если вам нужно больше тестов в стиле XUnit, посмотрите Тест :: Класс. Он предоставляет атрибуты Test(setup) и Test(teardown) для методов, которые настраивают и разрушают вашу среду. Это также дает вам гораздо более удобный способ работы с планами (вы можете предоставить один для каждого метода тестирования индивидуально, поэтому подсчет намного менее сложен) и позволяет вам наследовать тесты через иерархии тестовых классов.

Если вы также готовы пройти приемочное тестирование, например Ruby's Cucumber - взгляните на этот небольшой пример http://github.com/kesor/p5-cucumber, который использует Test :: More и стиль приемочного тестирования огурца.