Как вы тестировали новые функции

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

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

Как отвечать

Возьмите одну фичу из опыта и пройдите по пирамиде:

• юнит-тесты: JUnit 5, AssertJ, Mockito для зависимостей. Проверяете логику и граничные случаи: пустой ввод, отрицательная сумма, повторный запрос;
• срезы Spring: @WebMvcTest для контроллера с валидацией и кодами ответа, @DataJpaTest для репозитория, без подъёма всего контекста;
• интеграционные: @SpringBootTest с Testcontainers, настоящие PostgreSQL и Kafka в контейнерах вместо H2, внешние HTTP-сервисы через WireMock. Здесь ловятся миграции, транзакции и сериализация;
• контракты: Spring Cloud Contract или Pact, если фича меняет API, которым пользуются другие команды;
• нагрузка: Gatling или JMeter, если есть требования по времени ответа.

Добавьте процесс: тесты пишутся в том же merge request, CI не пропускает красную сборку, покрытие смотрите в JaCoCo как подсказку, а не цель. Сильно звучит мутационное тестирование PIT, если пробовали. Рискованную фичу прячут за feature flag и включают сначала на части пользователей.

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

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

Называют интеграционным тест, где все зависимости замоканы через Mockito. Это юнит-тест, интеграцию он не проверяет.

Тестируют на H2 вместо той базы, что в проде. Диалект, типы и блокировки отличаются, и тесты зелёные ровно до релиза.

Говорят «повысили удовлетворённость пользователей» без единого факта. Один реальный пойманный баг убеждает сильнее общей фразы про качество.