Существуют ли соглашения для имен функций при использовании Perl Test :: More? - PullRequest
3 голосов
/ 05 сентября 2008

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

Я специально спрашиваю об именах функций, которые используются для настройки тестовой среды перед тестом и для разрушения среды после успешного завершения тестов.

ура

Rob

Ответы [ 8 ]

4 голосов
/ 16 сентября 2008

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

3 голосов
/ 05 сентября 2008

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

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

1 голос
/ 05 сентября 2008

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

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

1 голос
/ 05 сентября 2008

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

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

Не похоже на серию тестов XUnit.

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

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

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

ура

Rob

1 голос
/ 05 сентября 2008

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

0 голосов
/ 13 марта 2009

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

0 голосов
/ 16 сентября 2008

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

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

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

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

0 голосов
/ 05 сентября 2008

Первое соглашение, которое я бы предложил - это тест на канаву :: Еще для теста :: Большинство

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...