Usually one would like to run specific JPA tests using an in-memory database to have a clean entry point. Executing tests of a single test class will not reveal any limitations of this approach. However running multiple test classes in a batch, like done in CI environments or by just typing mvn test might expose an unexpected limitation: a database (schema and contents) from the execution of a previous test class might still be there and interfere with the execution of the current test class. This is mainly related to when an in-memory database is removed. Most vendors do this when the last connection to the database is closed. Since JPA provider implement and rely on connection pooling, additional time is required to close these connections after closing of the EntityManagerFactory instance. This limitation can only occur if no database cleanup is done by the preceding test class or during the bootstrapping of the current test class.
Here some examples which also describe possible workarounds:
A preceding test class and the current test class differ in the JPA provider configuration, where the former drops and creates the data base schema and the latter relies on the presence of it, e.g. done in a specific bootstrapping method. In such case one should drop the data base schema in the bootstrapping method.
A preceding test class and the current test class use the same JPA provider configuration, where both rely on the presence of the database schema, e.g. done in a specific bootstrapping method. In such case the latter test class will fail to bootstrap the database schema because of its presence. To overcome this, one should drop the data base schema in the bootstrapping method.
The preceding and the current test classes use the same JPA provider configuration, but the last executed test method of the previous test class does not clear (cleanup using @Cleanup is disabled) the database contents. In such case one should add the @Cleanup annotation to the last method (consider the execution order of the test methods) of that test class or clear the database contents in the bootstrapping method.
Usually one would like to run specific JPA tests using an in-memory database to have a clean entry point. Executing tests of a single test class will not reveal any limitations of this approach. However running multiple test classes in a batch, like done in CI environments or by just typing
mvn test
might expose an unexpected limitation: a database (schema and contents) from the execution of a previous test class might still be there and interfere with the execution of the current test class. This is mainly related to when an in-memory database is removed. Most vendors do this when the last connection to the database is closed. Since JPA provider implement and rely on connection pooling, additional time is required to close these connections after closing of theEntityManagerFactory
instance. This limitation can only occur if no database cleanup is done by the preceding test class or during the bootstrapping of the current test class.Here some examples which also describe possible workarounds:
@Cleanup
is disabled) the database contents. In such case one should add the@Cleanup
annotation to the last method (consider the execution order of the test methods) of that test class or clear the database contents in the bootstrapping method.