Стоит ли фокусироваться на настройке Spring для тестов
Что проверяют
Понимаете ли вы, что подъём контекста это самая дорогая часть теста, и умеете ли выбирать уровень изоляции. По ответу видно, писали ли вы тесты в большом проекте, где прогон идёт минутами.
Как отвечать
Скажите, что настройка стоит внимания ровно потому, что от неё зависит время обратной связи, и разложите по уровням.
Логика без фреймворка проверяется обычным тестом: объект создаётся конструктором, никакого контекста. Таких тестов должно быть большинство, и именно внедрение зависимостей через конструктор делает их возможными.
Когда фреймворк нужен, берут срезы вместо полного контекста: срез веб-слоя поднимает контроллеры и сериализацию, срез слоя данных поднимает репозитории и транзакции. Полный запуск приложения оставляют для нескольких сквозных проверок.
Главное про скорость: контекст кэшируется между тестовыми классами по совокупности настроек. Любое отличие, свой набор профилей, своё переопределение бина, лишнее свойство, порождает ещё один контекст в памяти. Поэтому тестовые конфигурации сводят к нескольким стандартным наборам и наследуют их, а не сочиняют новую на каждый класс.
Базу берут настоящую, в контейнере, поднятом один раз на весь прогон. Встроенная в память база отличается диалектом, типами и поведением блокировок, и часть ошибок она просто не воспроизводит, зато даёт зелёный прогон и ложную уверенность.
Где спотыкаются
Ставят полный запуск приложения на каждый тестовый класс, подменяя внешние вызовы точечно. Прогон распухает до минут, и команда перестаёт запускать тесты локально, а значит узнаёт о поломке только от сборки.
Второе: лечат медленный прогон принудительным сбросом контекста, считая это оптимизацией. Аннотация делает ровно обратное: выбрасывает контекст из кэша, и следующий класс поднимает его заново.
Третье: подменяют бины в контексте там, где хватило бы обычной заглушки, переданной в конструктор. Каждая такая подмена создаёт отдельный кэшированный контекст, и самые простые тесты становятся самыми дорогими.