Достойны ли юнит-тесты для JPA? в любом случае, это просто доступ к БД, зачем нам это нужно?

Question

Достойны ли модульные тесты для JPA? в любом случае, это просто доступ к БД, зачем нам это нужно?

Answer 1

Я не согласен с большинством ответов до сих пор. Для большинства корпоративных приложений большая часть бизнес-логики встроена в запросы к базе данных, большинство в JPQL, если вы используете JPA, а некоторые могут быть довольно сложными. Это код, который вы пишете, и поэтому вы должны его проверить.

Если запросы просты - без сложных объединений или критериев - тогда это не столь серьезная проблема, но, по моему опыту, эти приложения редки, и вам, вероятно, не нужно что-то более мощное, чем JPA, для их создания , Вы будете платить с точки зрения масштабируемости для приложений, которые наивно пытаются сохранить свой уровень постоянства свободным от «бизнес-логики».

Для большинства приложений JPA жизненно важно, чтобы тесты выполнялись вне контейнера как часть вашей обычной, постоянно интегрированной сборки. Типичный способ сделать это - использовать базу данных в памяти, такую ​​как HSQLDB или H2.

Java EE конкурирует с фреймворками, такими как Rails и Django, которые ожидают, что разработчик проведет модульное тестирование своего кода на реальной базе данных, специально предназначенной для этой цели. Разработчики JPA должны ожидать не меньше.

Answer 2

вы можете использовать встроенную базу данных, например HSQLDB или База данных H2 и:

• проверка правильности сопоставления аннотаций (как в SessionFactory можно запустить)
• использовать некоторую "маленькую" схему.sql для проверки ограничений (например, длина строки, внешний ключ)
• взглянем на операторы SQL, чтобы обнаружить некоторые странные отображения

и / или использовать базу данных интеграции (удаленную или созданную локально с резервными копиями с производства) и:

• сделать некоторые тесты производительности или реальных данных

Answer 3

Модульные тесты обычно предлагаются для

• вещи, которые вы пишете (не библиотеки / рамки)
• вещи, которые могут часто ломаться
• вещей, которые попадают в логику приложения код

код JPA

• написано не вами, а другими людьми
• если вы используете хорошую библиотеку (hibernate / toplink), код уже зрелый
• постоянство НЕ бизнес-логика

ИМХО вам не следует делать юнит-тест для JPA. Для крайних случаев используйте DbUnit, как уже упоминалось.

Answer 4

Мой опыт работы с модульным тестированием приложения, над которым я работаю, первоначально привел меня к созданию «модульных тестов» для доступа к нашему ORM, требующих, чтобы база данных работала в фоновом режиме. Очевидно, что это НАМНОГО более тяжелый, чем вы хотите, чтобы был модульный тест, а для настройки / демонтажа требуется создание и удаление данных через ORM, а также получение доступа к базе данных, это действительно интеграционный тест, но это не причина, чтобы его не делать , Я делаю это, поскольку у нас много логики в базе данных, и это довольно простой способ получить к нему доступ, используя код, который все могут понять, в вашем случае, я думаю, вам нужно спросить, есть ли какой-то ваш собственный код, который вы на самом деле будете использовать проверьте это.

Answer 5

Вы можете использовать DbUnit для тестирования базы данных с JPA, если у вас очень сложный запрос, вы можете проверить, работает ли он с реальным БД (dbunit использует гиперзвуковые для тестов). Однако для подготовки данных к тестированию требуется некоторое время, поэтому запись выполняется гораздо медленнее, чем при модульном тестировании с использованием имитаций. это может быть излишним, но вы должны попробовать и посмотреть, как вам это нравится. Я думаю, что оно того не стоит.

Answer 6

Я никогда не делал юнит-тесты для сущностей JPA. Я провожу модульное тестирование бизнес-логики, в которой вы либо будете использовать сущности / запросы JPA напрямую, либо будете издеваться над запросами.

Любая разумная IDE проверит модель JPA так, что все имена таблиц и столбцов будут правильными. Как только это будет сделано, что еще можно сделать? Проблема с запросами модульного тестирования заключается в том, что вы должны ожидать, что определенные данные будут проверять тест, а я никогда не был фанатом создания поддельных данных только для того, чтобы пройти тест.