Почему выбирают Kotest? | OTUS >
Скидки 5% на курсы из спецкаталога
Скидки 5%
Действуют до 21 июня. Дальше скидок не будет…
Действуют до 21 июня. Дальше скидок не будет…
Перейти

Почему выбирают 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 комментариев
Для комментирования необходимо авторизоваться
Популярное
Сегодня тут пусто