Почему выбирают Kotest? | OTUS
🎅 Декабрьская распродажа в OTUS!
Новый год – новые знания. Сделайте себе подарок и приобретите интересующий вас курс по самой выгодной цене декабря ❄️
Выбрать курс

Почему выбирают Kotest?

Kotest (kotlintest) представляет собой гибкий комплексный инструмент для написания автоматизированных тестов на Kotlin. С его помощью вы можете создавать тесты, применяя для этого разные стили. Вот простейший пример теста:

1-1801-a635bc.png

К сожалению, на практике многие специалисты по автоматизированному тестированию не уделяю должного внимания выбору тестового фреймворка, продолжая использовать Junit4/Junit5. Как правило, для таких тестировщиков тесты представляют собой приблизительно следующее: — класс, который помечен аннотацией @SpringBootTest; — набор методов, помеченных аннотацией @Test; — возможно, но не обязательно, методы before и beforeClass, тоже помеченные соответствующими аннотациями.

Однако для полноценных функциональных end-2-end-тестов этого явно недостаточно, ведь требуется инструмент, который не только позволяет создавать понятные автотесты на основе требований, но и обеспечивает удобную организацию отчетности, проверок, тестовых данных.

v5e5bdqn6wzbubebhh1lkni0iiw_1-1801-dd85b4.png

Какие возможности предоставляет нам Kotest:

• можно писать предельно понятные тесты в стиле BDD, используя для этого Kotlin DSL и функции расширения; • можно относительно легко создавать data driven-тесты в функциональном стиле; • можно определять обратные вызовы перед тестом и тестовым классом, а также после них (посредством DSL); • можно определить действия на уровне всего тестового прогона (такой фичи нет в junit, по крайней мере, явно); • можно задействовать встроенные интуитивные проверки; • можно относительно просто конфигурировать тестовые классы и тестовый проект из кода; • можно много чего еще: подробности лучше смотреть в официальной документации и в проекте на GitHub.

Скажем несколько слов и про минусы в контексте ассертов: • если надо подключить только ассерты, придется поковыряться — сходу понять бывает тяжело; • нет варианта ловли exception с явным параметром, а не reified, однако на практике это может особо и не надо — вряд ли вы будете этим заниматься; • могут быть проблемы по обработке сложных структур: к примеру, автотест со вложенными массивами может не пройти; • интеграция <Click to see difference> существует лишь для простых ассертов; • типизация: в некоторых случаях при применении дженериков следует писать им явный тип; • описание ошибок: в принципе, реализовано практически идеально, разве что не хватает подробностей отличия двух множеств.

Источники: • 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.

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

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

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

Автор
0 комментариев
Для комментирования необходимо авторизоваться