Introduce a TestExecutionListener for DbUnit [SPR-6593]

[spring-projects-issues]

Dave Syer opened SPR-6593 and commented

Primary Goal

Add a TestExecutionListener for DbUnit.

Related Resources

• Phil Webb's spring-test-dbunit project on GitHub
• Proposal to include DbUnit support in Spring Data JDBC instead of in Spring Core
• JBoss Arquillian Persistence Extension

---

Issue Links:

• Provide @Rule alternative to SpringJUnit4ClassRunner [SPR-7731] #12387 Provide @Rule alternative to SpringJUnit4ClassRunner ("Cloned to")
• BATCH-1158 Enabling unit testing of batch jobs with DbUnit/Unitils ("is duplicated by")
• Transactional unit test support without overhead of container [SPR-7551] #12208 Transactional unit test support without overhead of container
• DATAJDBC-28 Introduce a TestExecutionListener for DbUnit
• Introduce before/after test execution callbacks in the TestContext framework [SPR-4365] #9043 Introduce before/after test execution callbacks in the TestContext framework
• Introduce explicit Hibernate and/or DbUnit support in the TestContext Framework [SPR-3096] #7783 Introduce explicit Hibernate and/or DbUnit support in the TestContext Framework ("supersedes")

5 votes, 7 watchers

[spring-projects-issues]

Dave Syer commented

WIth modern JUnit (4.7 perhaps but to be safe 4.8.1) it is good style to use @Rule for enhancing test methods. A rule that loaded an SQL script per method could be configured in Spring and injected with the data source, then injected by the test context listener into the test case. E.g.

@Autowired
@Rule
public SqlLoader loader;

@Test
@Transactional
public void testSomething() {
  // Loader looks for an SQL script based on a naming convention from the test method
}

[spring-projects-issues]

!!Use pwebb rather than philw commented

I have been working on some code to provide Spring DBUnit integration that could perhaps form the basis of a patch for this feature. The code allows for @DatabaseSetup and @DatabaseTeardown annotations to applied to test classes/methods. There is also a @ExpectedDatabase annotation that can be used to confirm the state of the database after a test method runs.

Annotations can be processed using a Spring TestExecutionListener or a @Rule if you are running JUnit 4.7+.

The code is hosted here
https://github.com/philwebb/spring-test-dbunit
See the README for documentation.

There is also a sample project here:
https://github.com/philwebb/spring-test-dbunit-example

Any feedback or comments are welcome.

[spring-projects-issues]

Sam Brannen commented

Have you guys looked at Carbon Five's custom DbUnit TestExecutionListener?

Does the DataSetTestExecutionListener meet your needs?

[spring-projects-issues]

Dave Syer commented

It's not as nice as the patch proposed by Phil - not as flexible and requires a base class from a quick scan. Why not just accept the contribution as it is?

[spring-projects-issues]

!!Use pwebb rather than philw commented

I did try to google for existing projects before I started coding but this one must have slipped though the net. By the way, they now have a google code project hosted here: http://code.google.com/p/c5-test-support/

I like the way that with C5 the a default dataset xml filename is loaded if there is no value on the annotation. That seems like a sensible choice. The datasource lookup is also nice, mine relies on a specific bean name (if not configured), where as C5 searches for any dataset.

I also notice that they use a ReplacementDataSet to support [NULL] in the dataset XML. I am not sure what advantage this gives over simply omitting the attribute from the XML but it is another feature.

I think Dave may be mistaken with the assertion that a base class is required to use the code. I think that is is just a convenience class and it does not need to be used.

Now, I may be a little biased here, but I think there are some things that my code offers over C5:

• Custom DatabaseDataSourceConnections can be used, if for example you want a specific configuration. I also provide a factory bean to help you create them with Spring.

• @DatabaseSetup and @DatabaseTeardown can be applied to both methods and classes. Having two seperate annotations also allows different dataset XMLs to be used for setup and teardown. The database operation is also a type safe enum with my implementation, rather than a String.

• @ExpectedDataset can be used to verify the state of the database once a test has finished.

• A strategy pattern is used to allow pluggable DataSetLoaders if the FlatXmlDataSet is not suitable.

I also have quite an extensive set of unit tests that cover a large proportion of the code.

Perhaps Spring/DBUnit integration is something that is better served by separate independent projects rather than adding to the core of Spring? I am happy to publish this code separately if does not fit will within Spring; or try to refine it if there are any specifics that you want changed.

Cheers,
Phil.

[spring-projects-issues]

Phil Webb commented

The source code for this project has now moved to https://github.com/springtestdbunit/spring-test-dbunit

[spring-projects-issues]

Phil Webb commented

See https://jira.springsource.org/browse/DATAJDBC-28

[spring-projects-issues]

Sam Brannen commented

Deleted references to Unitils since this issue focuses on DbUnit support.

See #9043 for the requested hooks to allow Unitils to integrate directly in the TestContext Framework.

[spring-projects-issues]

Juergen Hoeller commented

It doesn't seem like there are any remaining intentions to add this to Spring Framework proper. To be reopened if we decide otherwise.

Juergen