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

Question

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

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

веселит,

Роб

Answer 1

Я не думаю, что есть какие-то такие конвенции там.

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

Answer 2

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

Answer 3

Спасибо, Espo.

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

Не похоже на ряд тестов XUnit.

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

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

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

веселит,

Роб

Answer 4

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

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

Answer 5

Первая конвенции я предлагаю это канавы Test :: Больше для испытания :: Большинство

Answer 6

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

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

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

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

Answer 7

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

Answer 8

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