0 added
0 removed
Original
2026-01-01
Modified
2026-03-10
1
<p>Теги: тестирование, kotlin, qa, автоматизация, kotest</p>
1
<p>Теги: тестирование, kotlin, qa, автоматизация, kotest</p>
2
<p>Для формирования структуры тестов фреймворк<strong>Kotest</strong>предоставляет возможность выбирать между несколькими вариантами DSL (Kotlin DSL - это<em>type-safe builder</em>). Давайте рассмотрим эти варианты.</p>
2
<p>Для формирования структуры тестов фреймворк<strong>Kotest</strong>предоставляет возможность выбирать между несколькими вариантами DSL (Kotlin DSL - это<em>type-safe builder</em>). Давайте рассмотрим эти варианты.</p>
3
<h3>Кратко о стилях</h3>
3
<h3>Кратко о стилях</h3>
4
<p>Наиболее простым и базовым является<strong>String Spec</strong>- этот вариант отлично подойдет, если надо написать unit-тесты с одним уровнем вложенности. Если же речь идет о полноценных и функциональных автоматизированных тестах, то тут уже следует подумать о чем-нибудь более сложном, таким, чтобы структура была схожа с<strong>Gherkin</strong>, однако была не так формализована, особенно по ключевым словам. В данном случае интересным вариантом станет стиль<strong>FreeSpec</strong>. Впрочем, стилей существует довольно много, подробнее о них читайте<a>здесь</a>. Главная рекомендация -- при использовании Kotest рекомендуется продолжать писать тесты в стиле BDD, то есть как в языке Gherkin (Cucumber). Также следует понимать, что FreeStyle не накладывает каких-либо ограничений на именование тестов, вложенность и ключевые слова, следовательно, все это необходимо контролировать на уровне best practice, code-style и Merge-Request`ов.</p>
4
<p>Наиболее простым и базовым является<strong>String Spec</strong>- этот вариант отлично подойдет, если надо написать unit-тесты с одним уровнем вложенности. Если же речь идет о полноценных и функциональных автоматизированных тестах, то тут уже следует подумать о чем-нибудь более сложном, таким, чтобы структура была схожа с<strong>Gherkin</strong>, однако была не так формализована, особенно по ключевым словам. В данном случае интересным вариантом станет стиль<strong>FreeSpec</strong>. Впрочем, стилей существует довольно много, подробнее о них читайте<a>здесь</a>. Главная рекомендация -- при использовании Kotest рекомендуется продолжать писать тесты в стиле BDD, то есть как в языке Gherkin (Cucumber). Также следует понимать, что FreeStyle не накладывает каких-либо ограничений на именование тестов, вложенность и ключевые слова, следовательно, все это необходимо контролировать на уровне best practice, code-style и Merge-Request`ов.</p>
5
<h3>Иерархия тестовых сущностей</h3>
5
<h3>Иерархия тестовых сущностей</h3>
6
<p>В выбранном подходе в рамках применения Kotest будут пять базовых тестовых уровней/сущностей. Определим их:</p>
6
<p>В выбранном подходе в рамках применения Kotest будут пять базовых тестовых уровней/сущностей. Определим их:</p>
7
<ol><li><strong>Execution</strong>(он же Project) -- тестовый прогон. Подразумевается запуск конкретного набора тестов.</li>
7
<ol><li><strong>Execution</strong>(он же Project) -- тестовый прогон. Подразумевается запуск конкретного набора тестов.</li>
8
<li><strong>Spec</strong>-- спецификация. Речь идет о тестовом классе. Например, в Cucumber - это Feature.</li>
8
<li><strong>Spec</strong>-- спецификация. Речь идет о тестовом классе. Например, в Cucumber - это Feature.</li>
9
<li><strong>Top Level Test</strong>-- контейнер теста. Это уже сценарий верхнего уровня в спецификации (Scenario в Cucumber).</li>
9
<li><strong>Top Level Test</strong>-- контейнер теста. Это уже сценарий верхнего уровня в спецификации (Scenario в Cucumber).</li>
10
<li><strong>Nested Test</strong>-- шаг теста. Шаг в сценарии, начинающийся с ключевого слова. То есть ключевое слово означает этап (например, подготовка -- это ключевое слово "Дано", воздействие -- "Когда", проверка ожидаемой реакции -- "Тогда"). Это Step в Cucumber.</li>
10
<li><strong>Nested Test</strong>-- шаг теста. Шаг в сценарии, начинающийся с ключевого слова. То есть ключевое слово означает этап (например, подготовка -- это ключевое слово "Дано", воздействие -- "Когда", проверка ожидаемой реакции -- "Тогда"). Это Step в Cucumber.</li>
11
<li><strong>Nested Step</strong>-- это уже вложенные шаги -- любая вспомогательная информация о выполненных действиях, к примеру, аннотация @Step в Allure. Тут важно отметить, что данные шаги не несут никакой нагрузки в рамках описания сценария, а нужны они преимущественно для отчета/отладки и выяснения причин ошибки. При этом фреймворк Kotest дает возможность создавать практически любую вложенность, однако в выбранном нами подходе мы ограничиваемся четырьмя шагами теста (Nested Test), а дальнейшая вложенность уже будет восприниматься в качестве шагов для отчета.</li>
11
<li><strong>Nested Step</strong>-- это уже вложенные шаги -- любая вспомогательная информация о выполненных действиях, к примеру, аннотация @Step в Allure. Тут важно отметить, что данные шаги не несут никакой нагрузки в рамках описания сценария, а нужны они преимущественно для отчета/отладки и выяснения причин ошибки. При этом фреймворк Kotest дает возможность создавать практически любую вложенность, однако в выбранном нами подходе мы ограничиваемся четырьмя шагами теста (Nested Test), а дальнейшая вложенность уже будет восприниматься в качестве шагов для отчета.</li>
12
</ol><p>Остается добавить, что с точки зрения Review и форматирования теста интерес представляют уровни 1-4.</p>
12
</ol><p>Остается добавить, что с точки зрения Review и форматирования теста интерес представляют уровни 1-4.</p>
13
<p>Также можно отметить следующий интересный момент: в<strong>Gherkin</strong>есть такая сущность, как<strong>Scenario Template</strong>-- структура сценария - это, по сути, реализация<strong>Data Driven</strong>. Что касается<strong>Kotest</strong>, то тут 3-й уровень<strong>Top Level Test</strong>(контейнер теста) тоже может являться такой структурой сценария и помножиться на наборы тестовых данных.</p>
13
<p>Также можно отметить следующий интересный момент: в<strong>Gherkin</strong>есть такая сущность, как<strong>Scenario Template</strong>-- структура сценария - это, по сути, реализация<strong>Data Driven</strong>. Что касается<strong>Kotest</strong>, то тут 3-й уровень<strong>Top Level Test</strong>(контейнер теста) тоже может являться такой структурой сценария и помножиться на наборы тестовых данных.</p>
14
<p><em>По материалам https://habr.com/ru/company/nspk/blog/.</em></p>
14
<p><em>По материалам https://habr.com/ru/company/nspk/blog/.</em></p>
15
15