Необходимы ли тесты репозитория Spring/Micronaut
Привет, сообщество stackru.
У меня на работе был спор о том, нужны ли вообще тесты репозитория для JPA с пружинными данными (или версии Micronaut).
Это будет моя установка приложения:
@Controller ➡ @Service/@Sigleton ➡ Repository<Entity>
в своих сервисных тестах я бы использовал @ExtendWith(SpringExtension::class) расширение (Junit5)
при создании тестовой установки я бы @MockBean прочь другие системы, которые мне нужно вызвать (например, REST-API), но @Autowire мой Repositoryс. При настройке моих тестовых данных я просто сохранял требуемые объекты в базе данных H2 в памяти, используя внедренные репозитории.
Это также проверит мою логику базы данных и бизнес-логику. В случае 100% тестового покрытия я протестировал все вызовы базы данных, которые могут произойти в производственной среде.
Однако в проектах я обычно вижу, что Repositoryвысмеивается. Для проверки вызовов пользовательского репозитория существуют отдельные тесты, чтобы убедиться, что функции репозитория работают должным образом.
Ваши комментарии по этому поводу. Вы предпочитаете подход без моков репозитория или с и почему?
2 ответа
У меня нет опыта работы с Micronaut, но я полагаю, что мой ответ применим к обеим средам:
Например, Spring поддерживает различные типы интеграционных тестов. По сути, тот факт, что вы запускаете контекст Spring в тесте, уже означает, что это больше, чем модульный тест. В общем, тестовый пакет Spring предназначен для интеграционных тестов.
Теперь весной есть аннотации вроде @DataJpaTest, @WebMvcTest. Они создают "кусок" контекста приложения, загружая только необходимые bean-компоненты и высмеивая / игнорируя другие. Например, в@WebMvcTest Репозитории JPA вообще не загружаются.
Вы также можете создавать свои собственные срезы.
Теперь, если вы хотите проверить свой уровень отдыха (контроллер определен правильно, запрос проверяется надлежащим образом, на запрос вы получаете ответ в правильном формате и т. Д.), Вы можете использовать @WebMvcTest.
Если вы хотите проверить правильность запросов sql, вы можете использовать @DataJpaTest (конечно, при условии, что вы работаете с JPA / Spring Data).
Теперь, если вы хотите протестировать логику службы, иногда вам даже не нужен интеграционный тест (загрузка контекста Spring), поскольку вы можете запустить модульный тест для служб и смоделировать вызовы репозитория или вызовы внешних служб, если они у вас есть.
Что касается подхода H2. Хотя люди используют его для тестирования уровня своей БД (SQL-запросы), иногда он работает не так, как ваша база данных в производственной среде. Это означает, что иногда вы не можете выполнить один и тот же SQL-запрос в тестах. Для этих случаев я рекомендую проект TestContainers: запустите Docker-образ вашей базы данных при запуске теста и остановите образ после его завершения.
Обновить
На основании комментария OP:
фреймворк уже позаботился о многих "запросах mysql", так почему я должен явно тестировать репозиторий?
Это субъективно, но позвольте мне сказать так: тесты - это инструмент для получения уверенности в коде, прежде всего для разработчика. Если разработчик хочет быть уверенным, что запрос ведет себя так, как ожидалось, тест - это инструмент, который может помочь. Конкретно в отношении запросов: возможно, запрос просто неправильный, может быть, это собственный запрос, который все равно следует проверить. Может быть, есть много запросов, которые запускаются один за другим. Только вам решать.
Стоит ли писать Unit-тесты для сервисов?
Ну, это зависит от того, что на самом деле делают сервисы. Если они запускают сложный алгоритм, который нельзя легко проверить с помощью интеграционных тестов (например, сервис требует различных имитаций в различных случаях), тогда могут быть выполнены модульные тесты для сервисов.
Кроме того, в целом модульные тесты намного быстрее, чем тесты Spring. Итак (опять же субъективно) мое личное правило: если вы можете получить уверенность в коде с помощью модульного теста - сделайте это. Если вам нужно проверить интеграцию - пройдите интеграционный тест.
Если ты не издеваешься над своим Repositoryв сервисных джунитах это интеграционный, а не модульный тест. И это нормально, если вы хотите, чтобы это было так.
Но если вы хотите писать модульные тесты, которые проверяют ваши отдельные слои, вы должны издеваться над своим Repository и напишите отдельные интеграционные тесты для Repository.