How to load DBUnit test data once per case with Spring Test

Question

Spring Test helpfully rolls back any changes made to the database within a test method. This means that it is not necessary to take the time to delete/reload the test data before each test method.

But if you use the @BeforeClass Junit annotation, then that forces the data loader to be static. A question that is explored here: Why must jUnit's fixtureSetup be static?

If the data initialization method is static, so must the data connection methods and the data source..and on and on...forcing everything to be static...which won't work. At which point, I ask - what good is Spring Test's ability to rollback changes when you have to delete/reload the test data anyway for every test??!?!

Rumery

Answer 1

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.

Entrammel

This is, in fact, exactly how I solved the problem, I just forgot to put my code/answer back into SO. Thanks for taking the time to do this for the next guy. – Rumery

Sounds good, but in practice the '@PostConstruct' of the other class is running before that of the DatabaseInitialiser, so it is of no use. Thanks for any help. – Deserved

@united-expression: can you expand on that? Which other class do you mean? In the example I have, Spring initializes the database initialiser before the test class, which works in the Cass outlined in the question. – Entrammel

I have another class managed by Spring annotated by '@Component', its '@PostConstruct' method accesses the DB so that class is being initialized before the database initializer. The workaround for now is using a custom annotation for the other class, but would prefer a better solution. Thanks. – Deserved

I liked your approach and I took it a step further. Check below... – Winsor

Answer 2

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.

Netti

Well that's bad practice. What do you think of the checked solution? – Domella

Answer 3

Spring Test and DbUnit is two excellent frameworks. But it doesn't make sense to combine them. Since Spring Test execute a rollback on the connection, it cleans up afterwards, while DbUnit cleans up and insert test data in the @Before method.

Use Spring if you're not dependent on any dynamic data and dbUnit otherwise.

Coppins

I find DBUnit's ability to load a database table from XML to be convenient. Does Spring Test have a capability like this? – Rumery

Yeah, I think Mats is wrong here. Loading test data from an XML file is a nice benefit to db testing with Spring. – Domella

Answer 4

Methods annotated with @BeforeTransaction run, like its name suggests, before the transaction of each test is started. If in such method you can detect if the test data is loaded, then one can load the data when needed.

Beware though that the data is left in your (in-memory) database for all subsequent tests.

We use this to load "static" data that would, in a production environment, also be bootstrapped into our database when starting it. This way we actually use exactly the same code and data for our tests, rather than relying on (DbUnit) exports that might become outdated.

Bareback

Answer 5

You can create a data initializer "bean", since the config is only run once. It follows the same principle as the main answer, but with less code and classes

@Configuration
class DBUnitTest_Config {
  protected String PATH = "";

  @Bean
  public DataSetConfig setupData(DataSource dataSource) throws SQLException {
    DataSetExecutorImpl executor = DataSetExecutorImpl.instance(new ConnectionHolderImpl(dataSource.getConnection()));
    DataSetConfig dataSetConfig = new DataSetConfig(PATH);
    executor.createDataSet(dataSetConfig);
    return dataSetConfig;
  }

}

Winsor