Поднимаете ли инфраструктуру для тестов

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

Умеете ли вы делать тесты воспроизводимыми и кто в команде за это отвечает. Вопрос отсеивает тех, кто пишет только юнит-тесты с моками и никогда не поднимал зависимости: в Java-сервисе большая часть багов живёт на стыке с базой и брокером.

Как отвечать

Опишите уровни и инструмент на каждом:

• юнит: JUnit 5 и Mockito, без поднятия контекста Spring, миллисекунды на тест;
• срезы: @WebMvcTest для контроллеров, @DataJpaTest для репозиториев, поднимается только нужная часть контекста;
• интеграционные: Testcontainers, то есть настоящий PostgreSQL, Kafka или Redis в докере на время прогона, а конфигурация подтягивается через @ServiceConnection либо @DynamicPropertySource;
• внешние HTTP-зависимости: WireMock со сценариями ответов, включая таймаут и ошибку сервера;
• контракт с соседями: Spring Cloud Contract или Pact, чтобы не поднимать чужие сервисы целиком.

Отдельно скажите про данные: схему накатывает Flyway или Liquibase той же миграцией, что и на проде, состояние между тестами откатывается транзакцией либо пересозданием контейнера. И про скорость: Spring кэширует контекст, но любой новый набор бинов или подменённый бин создаёт ещё один контекст, поэтому разных тестовых конфигураций держат немного. В CI полезно разделить быстрый и долгий прогон, чтобы обратная связь на коммит приходила за минуты.

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

Подменяют базу на H2 и называют это интеграционным тестом. Диалект, типы вроде jsonb, оконные функции, блокировки и upsert ведут себя иначе: тесты зелёные, прод красный.

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

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