Тестирование с помощью Hibernate: цепочка зависимостей объектов от персистентности

Я готовлю модульные тесты для слоя DAO, который взаимодействует с объектами сущностей для сохранения в базе данных.

Технология Hibernate Java 1.6 JUnit

Предположим, я хочу создать тестовый метод addEntityA().

для этого я создаю объект EntityA. Теперь проблема в том, что EntityA является дочерним элементом EntityB. Поэтому я должен указать ссылку на EntityB в EntityA. EntityA будет сохраняться в базе данных только в том случае, если EntityB будет сохранен первым. Таким образом, для проверки постоянства EntityA у меня будет проверка постоянства EntityB. таким образом, это может привести к цепочке сущностей, которые должны быть сохранены до фактического сохранения EntityA для тестирования. Кто-то может возразить, что я должен указать ссылку на объект EntityB, который уже сохранен. Но проблема в том, что я не хочу, чтобы тестовые случаи зависели от теста в базе данных, а не от тестовых данных. Чем-то я похож на то, что решает JMock, но не уверен, как и может ли Jmock быть здесь полезным?

Пожалуйста, дайте мне знать, если проблема не ясна?


person Maddy.Shik    schedule 30.12.2010    source источник


Ответы (2)


Не уверен, каков ваш фактический вопрос, но лучший подход для тестирования функциональности Hibernate/JPA - использовать базу данных в памяти и достойную тестовую обвязку. Под тестовой обвязкой я имею в виду базовый класс для ваших классов, связанных с постоянством, который будет создавать и удалять вашу базу данных в памяти для каждого теста (возможно, только для каждого тестового класса). Тестовая система также должна обеспечивать доступ к диспетчеру сущностей или сеансу, который вы используете во время тестирования. Если вы используете фильтрацию для своих файлов конфигурации, вы можете использовать свойства для переключения баз данных, чтобы также протестировать «настоящие» базы данных. И последнее, но не менее важное: если для вашего теста EntityA требуется EntityB, вам нужно будет создать EntityB в настройках теста или в самом тесте. Взгляните на тестовую программу Hibernate Core, чтобы понять, как там проводится тестирование.

person Hardy    schedule 30.12.2010

Разделите проблему на две части. Ваш производственный код зависит от чистого интерфейса, который можно имитировать по мере необходимости. А затем реализуйте этот интерфейс с помощью уровня, который взаимодействует с базой данных. Протестируйте этот уровень с экземпляром реальной базы данных, поскольку сбои Hibernate чаще связаны с сопоставлениями, чем с кодом. Найдите дополнительные идеи в разделе «Архитектура портов и адаптеров».

person Steve Freeman    schedule 31.12.2010