Тестирование модулей и интеграция Тестирование разграничения в модуле уровня базы данных maven

Question

Я считаю, что совершил ту же ошибку, когда речь заходит о тесте, который я должен написать. в нашем приложении есть разные модули maven, и есть один под названием model, в котором есть все pojos, daos, hibernate. Он выполняет только операции CRUD и не знает обо всех остальных модулях.

Ну, после написания DAO я чувствую, что у меня есть тест, который фактически доказывает, что объекты сохраняются, удаляются и т. Д. На самом деле это тест на интеграцию вместо того, что я читал до сих пор.

Выполнение юнит-теста с макетами и на другом не имеет смысла для меня, поскольку это касается операций CRUD.

Теперь я как бы разделился на позицию, которую нужно принять, когда дело доходит до тестирования этого модуля.

Какая лучшая практика здесь? что это сделано в правильном проекте?

спасибо за чтение

Answer 1

Есть несколько подходов, которые я могу придумать.

Можно было бы просто придерживаться того, что вы делаете, называется ли это интеграцией или модульным тестом. Обычно модули такого типа имеют очень мало бизнес-логики для тестирования, поэтому операции CRUD - единственная проверяемая вещь. Если у вас есть легкодоступная база данных, и вы разрабатываете свои тесты для очистки после себя, это было бы просто замечательно. Еще лучше, если у вас есть база данных, которую вы можете просто сбросить до начала теста.

Другой подход, используемый во многих местах, - это использование в базе данных памяти для тестирования (например, Hypersonic). Но поскольку вы используете другую базу данных, вы не тестируете именно тот продукт, который вы создаете. Тем не менее, он проверит ваше отображение и запросы Hibernate (которые не относятся к целевым БД), что, возможно, является наиболее важным аспектом тестирования вашего модуля.