How to load DBUnit test data once per case with Spring Test
One approach that works is to create a "data initialiser" class, add it to a test Spring application context that also has your data source, and wire this application context into your tests. This relies on the fact that Spring caches the application context between test invocations.
For example, a test superclass:
@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(locations={"classpath:test-application-context.xml"})
@Transactional
public abstract class DataLoadingTest {
@Autowired
protected DatabaseInitialiser databaseInitialiser;
}
With test-application-context.xml
:
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd">
<bean id="dataSource" .../>
<bean class="DatabaseInitialiser">
<property name="dataSource" ref="dataSource"/>
</bean>
</beans>
And
public class DatabaseInitialiser extends JdbcDaoSupport {
@PostConstruct
public void load() {
// Initialise your database here: create schema, use DBUnit to load data, etc.
}
}
In this example:
- all tests that rely on the database extend
DataLoadingTest
; - Spring initialises the application context upon first test invocation;
- this calls
DatabaseInitialiser.load()
, via the@PostConstruct
annotation; - Spring keeps the application context in a cache;
- further test invocations wire in the
DatabaseInitialiser
from the application context, which is already cached; - tests are transactional, and roll back at the end to the initial data set.
Likewise, DatabaseInitialiser
can have a method annotated @PostDestroy
to perform any rollback necessary at the end of the whole test run.
We use DBUnit in conjunction with Spring Test extensively. But we do not use the DBUnit functionality to delete data at the end of the test.
We put a bunch of DBUnit inserts for our test data in the @Before method to initialise the test. Then when the test is complete we let the spring rollback functionality bring the database back to its original state.
The biggest problem we have with this is that the DBUnit data has to be loaded before each test, which can be a major performance hit. Most of our tests using DBUnit are read only, testing the behaviour of the application based on certain predefined behaviour. So we have a habit of creating master tests that then run all the fine grain tests in a batch within the same transaction.