Общие правила
Имена тест-кейсов формулируются как требования к желаемому свойству поведения SUT в терминах конечного пользователя/заказчика/продакта. В частности, в формулировке кейсов на операции системы не должны фигурировать символы из контрактов, схемы БД, классов и т.п. Исключение - в кейсах на методы API допустимо в скобках указывать метод и путь для упрощения навигации. Уточнение - в компонентных и юнит тестах "конечным пользователем" является разработчик.
Для каждого свойства рекомендуется писать минимум по два кейса.
Кейсы пишутся на языке команды - том языке на котором проходит большая часть коммуникаций внутри команды.
Общий шаблон названия тест-кейса: <SUT - прописан в имени класса>[при <характеристика состояния БД или запроса>] должен <требование к возвращаемому результату и/или наблюдаемым эффектам>[ - slug сценария - добавляется при наличии более двух сценариев проверки одного свойства поведения SUT].
Мотивация: такой подход подталкивает разработчика к тому, чтобы формулировать и кодировать кейсы с фокусом на конечного пользователя, а не на реализацию. Это позволяет создавать более ценные и устойчивые тесты, которые остаются актуальными даже при изменении внутренней структуры системы.
Примеры
Метод API получения списка препаратов (GET /diary/medications/v1)
при запросе от старых версий МП должен возвращать препараты для российского рынка - запрос без указания языка;
при запросе от старых версий МП должен возвращать препараты для российского рынка - запрос без указания страны;
должен возвращать название препарата <Другое> на запрошенном языке - запрос с указанием изначального языка системы;
должен возвращать название препарата <Другое> на запрошенном языке - запрос с указанием нового языка системы;
при запросе с неподдерживаемым языком должен вернуть ошибку запроса;
при запросе c фильтрацией по дате модификации должен возвращать только препараты изменённые строго после запрошенной даты - есть точное совпадение;
при запросе c фильтрацией по дате модификации должен возвращать только препараты изменённые строго после запрошенной даты - нет точного совпадения;
Метод API создания препарата (POST /diary/medications/v1)
должен сохранять препарат с указанными данными в БД - запрос с полным набором данных;
должен сохранять препарат с указанными данными в БД - запрос с минимальным набором данных;
Оформление в JUnit 6 + Kotlin коде
Классы пишутся по одному на SUT - эндпоинт, класс операции, метод класса ресурса и т.п. - в зависимости от контекста. В JUnit тест-кейсах имя SUT выносится в имя класса в DisplayName.
Название кейса по шаблону выше выносится в DisplayName тестового метода, а сам метод называется по шаблону test_<test-num>.
Где <test-num> - это порядковый номер кейса для данного свойства поведения SUT, который никогда не меняется.
@DisplayName("Метод API получения списка препаратов (GET /diary/medications/v1)")
class GetMedicationsApiTest {
@Test
@DisplayName("при запросе от старых версий МП должен возвращать препараты для российского рынка - запрос без указания языка")
fun test_01() {
// Given
// When
// Then
}
@Test
@DisplayName("при запросе от старых версий МП должен возвращать препараты для российского рынка - запрос без указания страны")
fun test_02() {
// Given
// When
// Then
}
@Test
@DisplayName("при запросе с неподдерживаемым языком должен вернуть ошибку запроса")
fun test_03() {
// Given
// When
// Then
}
}Отброшенные альтернативы:
Использование строго английского языка. В моей практике, где команды обычно имеют низкий уровень владения английским, это приводит к появлению имён кейсов, которые невозможно декодировать и, как следствие сложно поддерживать.
Использование бэктиков (именование методов на русском с пробелами). В целом это работает, но несёт пару небольших неудобств:
IDEA по умолчанию подсвечивает такие тесты;
Несколько раз возникали проблемы с компиляцией таких тестов;
На длину имени метода есть ограничение;
В именах методов не поддерживаются некоторые символы, например кавычки, которые могут быть полезны для указания конкретных значений в кейсе.
Не работает двойной клик на стектрейс для быстрого выбора символа для поиска в IDE.
У кейсов нет стабильных идентификаторов, что затрудняет ссылку на них в документации, багрепортах и планах по изменению т.п.
Использование slug в именах тестов.
Это создаёт дублирование - со временем slug и DisplayName могут расходиться, что приводит к путанице.
Это усложняет идентификацию кейсов - slug-и сами по себе не очень удобные, а если комбинировать slug-и с номерами, то это создаёт возможность дублирования номеров.