База данных для тестирования Junit

Question

Я кодирую crud API для моего приложения, построенного на Hibernate/SQL. Я использую mysql для тестирования и для живой среды.

Для тестирования у меня есть база данных, пользователь и привилегии. Поэтому каждый раз, чтобы проверить, я должен выполнить следующие шаги:

1. Удалить все таблицы из базы данных.
2. Запустите «mvn clean install», а спящий режим ищет таблицу в db и создает их, если они не существуют.

Я хочу, чтобы мое тестирование таким образом, что оно не собирает мусор в моем mysql db, и мне не нужно отбрасывать таблицы каждый раз. Есть ли некоторые rdbms в памяти, которые могут быть использованы для этой цели, и как я могу выбрать между этим и mysql в зависимости от среды выполнения для тестирования или использования.

Answer 1

Я предпочитаю использовать H2, dbUnit и spring-test. Hsqldb и Derby - это другие базы данных в памяти, которые являются разумными. Тесты весной используют свой собственный отдельный контекст со своим собственным источником данных, конфигурация тестового контекста заменяет обычные значения контекста приложения. Таким образом, нет никаких дополнительных усилий, необходимых для переключения между базами данных, тесты могут быть настроены на использование H2, в то время как приложение использует mysql.

Помните, что mysql разрешает использование sql, которое он принимает, другие базы данных имеют тенденцию быть более строгими. Если вы используете native sql, который может стать препятствием для использования базы данных в памяти.

Я думаю, что это платит, чтобы иметь тесты, осуществляющие ваш уровень данных, особенно при использовании Hibernate, что достаточно сложно, что я хочу подтвердить, что он действительно делает то, что я думаю, что он должен делать.

Answer 2

HSQLDB и H2 Я думаю, что это довольно распространенный выбор.

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