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

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

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

74684344_53426c00_51d4_11ea_8465_d78cf711a9f2_1-1801-a6abac.png

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

Наиболее простым и базовым является 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 (контейнер теста) тоже может являться такой структурой сценария и помножиться на наборы тестовых данных.

1-1801-ba947b.png

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

Не пропустите новые полезные статьи!

Спасибо за подписку!

Мы отправили вам письмо для подтверждения вашего email.
С уважением, OTUS!

Автор
0 комментариев
Для комментирования необходимо авторизоваться
Популярное
Сегодня тут пусто
🔥 Выгодные предложения!
Успейте начать обучение со скидкой до 10%. Акция до 31 июля →