Comments 5
Для тестов подойдёт даже простой NoOpCacheManager
Нет, не подойдёт. Нахрена нужен тест, который тестирует совершенно не то окружение, в котором предполагается работа?
Есть юнит тесты. Даже для интеграционных не обязательно поднимаются все интеграции.
Есть юнит тесты
Согласен. Но в данном случае, кэш-менеджер - это осознанно добавленная зависимость. Соответственно, она должна быть протестирована. Возможно, не эти тесты (с поднятием всех нужных зависимостей) могут быть неполными и покрывать только happycase, но они должны быть. Иначе можно вообще все интеграции NoOp-моками заменить. Просто чтобы тесты позеленить.
Иногда для тестов удобно использовать отличные от прода настройки: отключить ретраи, кеширование - так меньше приходится заботиться об очистке ресурсов между запусками и поведение более простое для отладки
Ключевое слово - "иногда". Конкретно в обсуждаемом случае, не та ситуация.
И ретраи, и кэширование тоже надо проверять. Хотя бы для того, чтобы понимать, что настроил их правильно.
Ещё раз, я не говорю, что полный аналог прода нужно запускать всегда, но минимальные happycase-ы проверять надо. Потому что банальная опечатка в имени свойства в лучшем случае приведёт к падению при разворачивании приложения на стенде, а если нет?
Приложение поднялось, как-то работает, а потом выясняется, что, например, конфиг для таймаута запроса в третьестороннюю систему вообще не задан. Вернее, ты думал, что задал, но ошибся в имени. И таймаут вечный. И всё, и привет. Причём, если на тестовых стендах эта третья сторона эмулируется, то о бесконечном таймауте мы можем узнать только на проде.
Spring Boot 4. Новые модули. Зачем?