Использовали ли Kotlin для написания автотестов

Что проверяют

Есть ли у вас реальный опыт и понимаете ли вы, что меняется, когда тесты Java-проекта пишутся на Kotlin. Следом обычно спрашивают, чем мокали и как обходили то, что классы в Kotlin по умолчанию final.

Как отвечать

Если опыт есть, опишите его конкретно: что тестировали (сервисы, API, UI), на каком стеке, почему команда выбрала Kotlin и что из этого вышло. Каркас по технологиям:

• JUnit 5: работает из Kotlin без переделок, имя теста можно написать в обратных апострофах, как фразу: `fun returns 404 for unknown user()`;
• Kotest: свои стили спецификаций, матчеры вроде shouldBe, property-based тесты. Spek из старых статей в новых проектах почти не берут;
• MockK: мокинг под Kotlin, умеет корутины (coEvery) и объекты-синглтоны. Mockito тоже подходит: с пятой версии он по умолчанию мокает финальные классы, а mockito-kotlin даёт whenever вместо конфликтующего с ключевым словом when;
• Spring: классы Kotlin финальные, поэтому для прокси нужен плагин kotlin-spring (allopen);
• API и UI: REST Assured с Kotlin-расширениями, Selenide, для Android Kaspresso.

Преимущества называйте проверяемые: data-классы для тестовых данных, именованные аргументы с умолчаниями вместо билдеров, DSL для читаемых сценариев.

Цифры приводите только свои и реальные. Если опыта нет, скажите прямо: тесты вы пишете на Java с JUnit 5, Mockito и AssertJ, Kotlin читаете, а разницу видите в синтаксисе, в работе с final и в выборе MockK. Это честнее и сильнее выдуманного проекта.

Где спотыкаются

Рассказывают про опыт, которого не было, и сыпятся на первом уточнении про final или корутины.

Верят, что Kotlin защищает от null везде. Значения из Java-кода приходят как платформенные типы, компилятор не проверяет их на null, и NPE в тестах случаются так же.

Не учитывают цену смешанного проекта: второй компилятор увеличивает время сборки, а Java-разработчикам команды придётся читать и поддерживать Kotlin.