С какими библиотеками для тестирования вы работали

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

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

Как отвечать

Разложите инструменты по назначению:

• JUnit 5: @Test, жизненный цикл через @BeforeEach, параметризация через @ParameterizedTest и @MethodSource, теги и параллельный запуск;
• Mockito: моки и стабы, when(...).thenReturn(...), проверка взаимодействий через verify, разбор аргументов через ArgumentCaptor;
• AssertJ: утверждения цепочкой и понятные сообщения о расхождении;
• Spring Boot Test: @SpringBootTest, когда нужен весь контекст, и срезы вроде @DataJpaTest и @WebMvcTest, когда не нужен;
• Testcontainers: настоящая база или брокер в контейнере вместо встроенной H2;
• WireMock: заглушки внешнего HTTP;
• TestNG: встречается в унаследованных проектах и в автотестах, группы и зависимости между тестами.

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

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

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

Поднимают полный контекст приложения на каждый класс. Сборка растягивается на минуты, а ловит такой тест ровно то же, что поймал бы срез или прямой вызов конструктора.

Проверяют слой данных на H2 вместо целевой СУБД. Диалекты расходятся: нативные запросы, типы, поведение при конфликте вставки, блокировки. Баг всплывает на стенде, и именно это закрывают Testcontainers.