Как оценивается процесс тестирования

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

Умеете ли вы судить о тестах по результату, а не по количеству. Интервьюеру важно, отличаете ли вы покрытие от качества проверок и понимаете ли, где тесты ловят дефекты, а где просто существуют. Следом обычно спрашивают: «У вас 85% покрытия, почему баги всё равно доходят до прода?»

Как отвечать

Разделите метрики на группы и для каждой назовите инструмент из Java-стека:

• покрытие: JaCoCo считает строки и ветки, в SonarQube на его основе строится quality gate для нового кода. Покрытие показывает, какой код ни разу не выполнялся, но не говорит, что проверки что-то проверяют;
• сила проверок: мутационное тестирование через PIT (pitest). Он вносит мелкие изменения в байткод и смотрит, упадёт ли хоть один тест. Доля убитых мутантов честнее процента строк;
• утечка дефектов: сколько багов нашли до релиза и сколько после. Если основная масса всплывает в проде, тесты стоят не там;
• стабильность и скорость: доля flaky-тестов и время прогона в CI. Набор, который идёт сорок минут и падает через раз, команда перестаёт слушать.

Дальше скажите про структуру. Юнит-тесты на JUnit 5 и Mockito гоняет Surefire на каждый коммит, интеграционные запускает Failsafe, а реальную базу и брокер для них поднимает Testcontainers. Процесс здоров, когда большинство проверок дешёвые и быстрые, медленных сквозных сценариев немного, а каждый упавший тест указывает на конкретную причину.

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

Называют покрытие главным критерием. Тест без единого assert даёт те же проценты, что и хороший, а погоня за цифрой порождает тесты на геттеры.

Меряют качество числом найденных багов. Их количество зависит от того, сколько багов внесли, и растёт при плохой разработке так же, как при хорошем тестировании.

Путают интеграционный тест с юнитом, в котором поднят весь контекст через @SpringBootTest. Такие тесты медленные, половина зависимостей в них всё равно замокана, и проверяют они в итоге немного.