JPA — как обрезать таблицы между модульными тестами

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

Убедитесь, что тесты не создают новых транзакций; вместо этого повторно используйте существующий.

Самый простой способ сделать это, вероятно, использовать метод jpa nativeQuery.

@After
public void cleanup() {
    EntityManager em = entityManagerFactory.createEntityManager();
    em.getTransaction().begin();
    em.createNativeQuery("truncate table person").executeUpdate();
    em.createNativeQuery("truncate table preferences").executeUpdate();
    em.getTransaction().commit();
}

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

Они также рекомендуют в качестве передовой практики не очищать или иным образом изменять данные после теста.

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

Да, проверка в транзакции значительно облегчит вам жизнь, но если вам нужна транзакция, вам необходимо реализовать компенсирующую транзакцию (транзакции) во время очистки (в @After). Это звучит трудоемко, и может быть, но при правильном подходе вы можете получить набор вспомогательных методов (в тестах), которые компенсируют (очищают) данные, накопленные во время @Before и тестов (с использованием JPA или прямого JDBC - что имеет смысл).

Например, если вы используете JPA и вызываете методы создания сущностей во время тестов, вы можете использовать (используя АОП, если хотите, или просто вспомогательные методы тестирования, такие как мы) шаблон во всех тестах, чтобы:

1. отслеживать идентификаторы всех объектов, которые были созданы во время теста
2. накапливать их в порядке создания
3. объекты воспроизведения удаляются для этих объектов в обратном порядке в @After

Моя установка очень похожа: это Derby (встроенный) + OpenJPA 1.2.2 + DBUnit. Вот как я обрабатываю интеграционные тесты для моей текущей задачи: в каждом @Before методе я запускаю 3 скрипта:

1. Drop DB скрипт SQL, который удаляет все таблицы.
2. Создайте БД сценарий SQL, который воссоздает их.
3. XML-скрипт модуля БД для конкретного теста для заполнения данных.

В моей базе данных всего 12 таблиц, а набор тестовых данных не очень большой, около 50 записей. Каждый скрипт выполняется около 500 мс, и я поддерживаю их вручную при добавлении или изменении таблиц.

Этот подход, вероятно, не рекомендуется для тестирования больших баз данных и, возможно, даже не может считаться хорошей практикой для небольших; однако у него есть одно важное преимущество перед откатом транзакции в методе @After: вы можете определить, что происходит при фиксации (например, сохраняющиеся отсоединенные объекты или исключения оптимистичной блокировки).

Лучше поздно, чем никогда... У меня была такая же проблема, и я нашел довольно простое решение:

1. установите для свойства "...database.action" значение "drop-and-create" в конфигурации вашего сохраняемого модуля.
2. закрывать менеджер сущностей и фабрику менеджеров сущностей после каждого теста

постоянство.xml

    <persistence-unit name="Mapping4" transaction-type="RESOURCE_LOCAL" >
    <provider>org.eclipse.persistence.jpa.PersistenceProvider</provider>
    <class>...</class>
    <class>...</class>

    <properties>
        ...
        <property name="javax.persistence.schema-generation.database.action" value="drop-and-create" />
        ...
    </properties>
</persistence-unit>

модульный тест:

...
@Before
public void setup() {
    factory = Persistence.createEntityManagerFactory(PERSISTENCE_UNIT_NAME);
    entityManager = factory.createEntityManager();
}


@After
public void tearDown() {
    entityManager.clear();
    entityManager.close();
    factory.close();
}

...

Я удаляю файл БД после каждого запуска:

boolean deleted = Files.deleteIfExists(Paths.get("pathToDbFile"));

Немного грязный, но работает для меня. С уважением

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

Вариант 2. База данных H2 уничтожает базу данных в памяти при закрытии последнего соединения. Я думаю, что Derby DB поддерживает что-то подобное, или вы можете переключиться на H2.

См. также: я написал код для усечения таблиц перед каждым тестом с использованием Hibernate в связанном вопросе: https://stackoverflow.com/a/63747005/471214