Тестовые классы PHPUnit с верблюжьим регистром или подчеркиванием

При написании тестовых случаев в стиле xUnit, которому следует PHPUnit, кажется, что все следуют соглашению о регистре верблюда для имен функций:

public function testObjectHasFluentInterface()
{
    // ...
}

Я назвал свои методы более «красноречивым» стилем PHPSpec:

public function test_it_has_a_fluent_interface()
{
    // ...
}

Создаст ли этот стиль проблемы для меня в будущем? Лично я нахожу его гораздо более читабельным и к нему легко вернуться.


unit-testing testing phpunit xunit phpspec
person AndrewMcLagan    schedule 31.12.2014    source источник

Ответы (2)


arrow_upward
3
arrow_downward

Вообще говоря: нет, в настоящее время это не вызовет у вас никаких проблем (я не вижу будущего, поэтому я не уверен, насколько этот ответ будет верным, скажем, лет через десять!).

Ссылаясь на руководство, если

тесты — это публичные методы с именами test*

PHPUnit будет рассматривать это как тест.

PHPUnit преобразует имена функций в верблюжьем регистре в правильно расположенные описания для вывода, поэтому test_it_has_a_fluent_interface будет отображаться как test it has a fluent interface (только что протестировано с версиями 4.0.17 и 4.4.1).

Кроме того, вы можете использовать аннотацию @test в докблоке метода, чтобы пометить его как метод тестирования.

person Bjoern    schedule 31.12.2014

arrow_upward
0
arrow_downward

Ваш более красноречивый стиль мало что меняет. Это по-прежнему набор слов, на этот раз с дополнительным разделением. Вместо этого я предлагаю более контекстный подход, основанный на следующем шаблоне:

methodUnderTest_ExpectedResultOrBehavior_OptionalConditions_OptionalContext

Ваш пример (ы) будет тогда:

public function testObject_HasFluentInterface
public function saveSale_ThrowsException_WhenTransactionDateIsYesterday
public function calculatePrice_ReturnsPrice_CalculatedIncludingPromotion
public function generateXml_CreatesXml_AndSavesItToFile_WhenAtLeastOneEntityExists

Это также дает вам своего рода структурное описание тела метода тестирования.

person k.m    schedule 31.12.2014
comment
Лично я нахожу это невероятно нечитаемым, сложным в обслуживании и сбивающим с толку будущих разработчиков. Похоже, вы описываете свои тесты в названии функции: ваш тестовый код должен читаться как история, вам не нужен такой уровень детализации. На самом деле это опасно в том смысле, что создает точку обслуживания: однажды разработчик на 100% обновит тест и не переименует функцию. БУМ юк. - person AndrewMcLagan; 29.03.2019
comment
Тесты должны начинаться с test, поэтому я не понимаю, почему последние три метода являются допустимыми примерами. - person Leo Galleguillos; 28.02.2020