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 (kotlintest)</strong>представляет собой гибкий комплексный инструмент для написания автоматизированных тестов на<strong>Kotlin</strong>. С его помощью вы можете создавать тесты, применяя для этого разные стили. Вот простейший пример теста:</p>
2
<p><strong>Kotest (kotlintest)</strong>представляет собой гибкий комплексный инструмент для написания автоматизированных тестов на<strong>Kotlin</strong>. С его помощью вы можете создавать тесты, применяя для этого разные стили. Вот простейший пример теста:</p>
3
<p>К сожалению, на практике многие специалисты по автоматизированному тестированию не уделяю должного внимания выбору тестового фреймворка, продолжая использовать Junit4/Junit5. Как правило, для таких тестировщиков тесты представляют собой приблизительно следующее: - класс, который помечен аннотацией @SpringBootTest; - набор методов, помеченных аннотацией @Test; - возможно, но не обязательно, методы before и beforeClass, тоже помеченные соответствующими аннотациями.</p>
3
<p>К сожалению, на практике многие специалисты по автоматизированному тестированию не уделяю должного внимания выбору тестового фреймворка, продолжая использовать Junit4/Junit5. Как правило, для таких тестировщиков тесты представляют собой приблизительно следующее: - класс, который помечен аннотацией @SpringBootTest; - набор методов, помеченных аннотацией @Test; - возможно, но не обязательно, методы before и beforeClass, тоже помеченные соответствующими аннотациями.</p>
4
<p>Однако для полноценных функциональных end-2-end-тестов этого явно недостаточно, ведь требуется инструмент, который не только позволяет создавать понятные автотесты на основе требований, но и обеспечивает удобную организацию отчетности, проверок, тестовых данных.</p>
4
<p>Однако для полноценных функциональных end-2-end-тестов этого явно недостаточно, ведь требуется инструмент, который не только позволяет создавать понятные автотесты на основе требований, но и обеспечивает удобную организацию отчетности, проверок, тестовых данных.</p>
5
<h3>Какие возможности предоставляет нам Kotest:</h3>
5
<h3>Какие возможности предоставляет нам Kotest:</h3>
6
<p>• можно писать предельно понятные тесты в стиле BDD, используя для этого Kotlin DSL и функции расширения; • можно относительно легко создавать data driven-тесты в функциональном стиле; • можно определять обратные вызовы перед тестом и тестовым классом, а также после них (посредством DSL); • можно определить действия на уровне всего тестового прогона (такой фичи нет в junit, по крайней мере, явно); • можно задействовать встроенные интуитивные проверки; • можно относительно просто конфигурировать тестовые классы и тестовый проект из кода; • можно много чего еще: подробности лучше смотреть в<a>официальной документации</a>и в<a>проекте на GitHub</a>.</p>
6
<p>• можно писать предельно понятные тесты в стиле BDD, используя для этого Kotlin DSL и функции расширения; • можно относительно легко создавать data driven-тесты в функциональном стиле; • можно определять обратные вызовы перед тестом и тестовым классом, а также после них (посредством DSL); • можно определить действия на уровне всего тестового прогона (такой фичи нет в junit, по крайней мере, явно); • можно задействовать встроенные интуитивные проверки; • можно относительно просто конфигурировать тестовые классы и тестовый проект из кода; • можно много чего еще: подробности лучше смотреть в<a>официальной документации</a>и в<a>проекте на GitHub</a>.</p>
7
<p>Скажем несколько слов и про<strong>минусы</strong>в контексте ассертов: • если надо подключить только ассерты, придется поковыряться - сходу понять бывает тяжело; • нет варианта ловли exception с явным параметром, а не<em>reified</em>, однако на практике это может особо и не надо - вряд ли вы будете этим заниматься; • могут быть проблемы по обработке сложных структур: к примеру, автотест со вложенными массивами может не пройти; • интеграция <Click to see difference> существует лишь для простых ассертов; • типизация: в некоторых случаях при применении дженериков следует писать им явный тип; • описание ошибок: в принципе, реализовано практически идеально, разве что не хватает подробностей отличия двух множеств.</p>
7
<p>Скажем несколько слов и про<strong>минусы</strong>в контексте ассертов: • если надо подключить только ассерты, придется поковыряться - сходу понять бывает тяжело; • нет варианта ловли exception с явным параметром, а не<em>reified</em>, однако на практике это может особо и не надо - вряд ли вы будете этим заниматься; • могут быть проблемы по обработке сложных структур: к примеру, автотест со вложенными массивами может не пройти; • интеграция <Click to see difference> существует лишь для простых ассертов; • типизация: в некоторых случаях при применении дженериков следует писать им явный тип; • описание ошибок: в принципе, реализовано практически идеально, разве что не хватает подробностей отличия двух множеств.</p>
8
<p><em>Источники:</em>• https://medium.com/kotlin-lang-notes/selenium-kotlintest-4db1da9811cc; • https://habr.com/ru/company/nspk/blog/520380/; • https://www.software-testing.ru/library/testing/testing-automation/3402-kotlin.</p>
8
<p><em>Источники:</em>• https://medium.com/kotlin-lang-notes/selenium-kotlintest-4db1da9811cc; • https://habr.com/ru/company/nspk/blog/520380/; • https://www.software-testing.ru/library/testing/testing-automation/3402-kotlin.</p>
9
9