Стили и иерархия тестовых сущностей в Kotest

Для формирования структуры тестов фреймворк Kotest предоставляет возможность выбирать между несколькими вариантами DSL (Kotlin DSL — это type-safe builder). Давайте рассмотрим эти варианты.

Кратко о стилях

Наиболее простым и базовым является String Spec — этот вариант отлично подойдет, если надо написать unit-тесты с одним уровнем вложенности. Если же речь идет о полноценных и функциональных автоматизированных тестах, то тут уже следует подумать о чем-нибудь более сложном, таким, чтобы структура была схожа с Gherkin, однако была не так формализована, особенно по ключевым словам. В данном случае интересным вариантом станет стиль FreeSpec. Впрочем, стилей существует довольно много, подробнее о них читайте здесь. Главная рекомендация -- при использовании Kotest рекомендуется продолжать писать тесты в стиле BDD, то есть как в языке Gherkin (Cucumber). Также следует понимать, что FreeStyle не накладывает каких-либо ограничений на именование тестов, вложенность и ключевые слова, следовательно, все это необходимо контролировать на уровне best practice, code-style и Merge-Request`ов.

Иерархия тестовых сущностей

В выбранном подходе в рамках применения Kotest будут пять базовых тестовых уровней/сущностей. Определим их:

1. Execution (он же Project) -- тестовый прогон. Подразумевается запуск конкретного набора тестов.
2. Spec -- спецификация. Речь идет о тестовом классе. Например, в Cucumber — это Feature.
3. Top Level Test -- контейнер теста. Это уже сценарий верхнего уровня в спецификации (Scenario в Cucumber).
4. Nested Test -- шаг теста. Шаг в сценарии, начинающийся с ключевого слова. То есть ключевое слово означает этап (например, подготовка -- это ключевое слово "Дано", воздействие -- "Когда", проверка ожидаемой реакции -- "Тогда"). Это Step в Cucumber.
5. Nested Step -- это уже вложенные шаги -- любая вспомогательная информация о выполненных действиях, к примеру, аннотация @Step в Allure. Тут важно отметить, что данные шаги не несут никакой нагрузки в рамках описания сценария, а нужны они преимущественно для отчета/отладки и выяснения причин ошибки. При этом фреймворк Kotest дает возможность создавать практически любую вложенность, однако в выбранном нами подходе мы ограничиваемся четырьмя шагами теста (Nested Test), а дальнейшая вложенность уже будет восприниматься в качестве шагов для отчета.

Остается добавить, что с точки зрения Review и форматирования теста интерес представляют уровни 1-4.

Также можно отметить следующий интересный момент: в Gherkin есть такая сущность, как Scenario Template -- структура сценария — это, по сути, реализация Data Driven. Что касается Kotest, то тут 3-й уровень Top Level Test (контейнер теста) тоже может являться такой структурой сценария и помножиться на наборы тестовых данных.

По материалам https://habr.com/ru/company/nspk/blog/.