Есть отличная удаленная работа для php+codeception+jenkins+allure+docker спецов. 100% remote! Присоединиться к проекту

[Resolved] Лучшая практика именования тестовых методов

design-patterns
java
testng
Теги: #<Tag:0x00007f7b704153a0> #<Tag:0x00007f7b70415210> #<Tag:0x00007f7b70415080>

(breakmt) #1

Хотел спросить у знающих людей - как вы посоветуете именовать тестовые методы? Читал что есть разные рекомендации к тому какой, так сказать, “стиль” наименования выбирать.

Разработку веду в связке Java + Webdriver + testNG. Я, как наверное и многие новички, пока использую наименования методов примерно такого вида:

testLoginAsParticipantWithIncorrectLogin

Потом задумался - а имеет ли вообще смысл начинать название каждого тестового метода со слова “test”? Видел некоторые используют первое слово “should”. Кто-то использует разделители “_”. Короче говоря, жду ваших советов по этому вопросу :blush:


(Mykhailo Poliarush) #2

А на каком языке Вы программируете?


(breakmt) #3

Извиняюсь, забыл упомянуть - Java


(Sergey Korol) #4

Ну сам стиль в любом случае должен соответствовать конвеншенам языка, т.е. применительно к Java - lowerCamelCase.

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

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


(Maksim Smolyakov) #5

Незначительно дополню. Имеет смысл в имени метода упоминать не только тестируемый объект/процесс, но и каким свойством он должен обладать, или какое поведение от него ожидается. Простой пример - emailFieldMustBeRequired().


(Mykhailo Poliarush) #6

Присоединюсь к @ArtOfLife и @msmolyakov. Только еще хочу добавить

Есть определенные конвенции, но _ особо не принято широко использовать, потому лучше не используйте, чтобы другим java специалистам не бросалось в глаза отступы от конвенций.

Ну и гугл тоже нам подсказывает чуток вспомнить о naming convention





(vmaximv) #7

А написав пару сьютов со “сложными” примерами - где название теста с трудом может уместиться на две строки, начинаешь просто их нумеровать, а “описательную часть” выносить в аннотации, что бы не ломать глаза ни себе не java-специалистам.


(Maksim Smolyakov) #8

Вы преувеличиваете. Сьюит на то и сьюит, что это набор нескольких автотестов, каждый из которых проверяет что-то свое. Если автотест выполняет множество действий и проверок, то всё же стоит попробовать разделить его на несколько малых автотестов.
Но я и не навязываю использовать такой подход повсюду. Разумеется, всё зависит от конкретного случая.


(vmaximv) #9

Дело не в сложности теста, а в невозможности построения полноценного DSL для сложных систем. Поэтому BDD так и не “взлетело”.

А теперь представьте что [quote]тестируемый объект/процесс[/quote]
описывается сложно-подчиненным предложением, не говоря уже про его свойства и поведение, которые вполне могут представлять из себя объекты/процессы ни чем не проще, чем тестируемый.

public void testSubmittingFormFromFormInputTextElementShouldFireOnSubmitForThatFormAndNotClickOnThatInput()