Хотел спросить у знающих людей - как вы посоветуете именовать тестовые методы? Читал что есть разные рекомендации к тому какой, так сказать, “стиль” наименования выбирать.
Разработку веду в связке Java + Webdriver + testNG. Я, как наверное и многие новички, пока использую наименования методов примерно такого вида:
testLoginAsParticipantWithIncorrectLogin
Потом задумался - а имеет ли вообще смысл начинать название каждого тестового метода со слова “test”? Видел некоторые используют первое слово “should”. Кто-то использует разделители “_”. Короче говоря, жду ваших советов по этому вопросу
Ну сам стиль в любом случае должен соответствовать конвеншенам языка, т.е. применительно к Java - lowerCamelCase.
В плане именования: всем должно быть понятно, что ваш тест проверяет, к примеру, sendBureauPaymentsWithSmartCard - тестируем отправку бюро платежей с использованием смарт карты. Указывать в названии слово test будет избыточным. Все итак поймут, что это - тест, увидев соответствующую аннотацию.
Тем не менее, есть правила именования тестовых классов при использовании определенных плагинов. Так что в имени класса упоминание Tests будет как раз в тему. Но восприятия общей картины это уж никак не испортит.
Незначительно дополню. Имеет смысл в имени метода упоминать не только тестируемый объект/процесс, но и каким свойством он должен обладать, или какое поведение от него ожидается. Простой пример - emailFieldMustBeRequired().
Есть определенные конвенции, но _ особо не принято широко использовать, потому лучше не используйте, чтобы другим java специалистам не бросалось в глаза отступы от конвенций.
Ну и гугл тоже нам подсказывает чуток вспомнить о naming convention
А написав пару сьютов со “сложными” примерами - где название теста с трудом может уместиться на две строки, начинаешь просто их нумеровать, а “описательную часть” выносить в аннотации, что бы не ломать глаза ни себе не java-специалистам.
Вы преувеличиваете. Сьюит на то и сьюит, что это набор нескольких автотестов, каждый из которых проверяет что-то свое. Если автотест выполняет множество действий и проверок, то всё же стоит попробовать разделить его на несколько малых автотестов.
Но я и не навязываю использовать такой подход повсюду. Разумеется, всё зависит от конкретного случая.
Дело не в сложности теста, а в невозможности построения полноценного DSL для сложных систем. Поэтому BDD так и не “взлетело”.
А теперь представьте что [quote]тестируемый объект/процесс[/quote]
описывается сложно-подчиненным предложением, не говоря уже про его свойства и поведение, которые вполне могут представлять из себя объекты/процессы ни чем не проще, чем тестируемый.
public void testSubmittingFormFromFormInputTextElementShouldFireOnSubmitForThatFormAndNotClickOnThatInput()
testomat.io управление авто тестами