Depending on newer versions of Spring.

[fbristow]

Spring 4.0.0 was released to GA yesterday (December 12, 2013). I would like to add Spring 4.0.0 as a dependency to my project, but can't right now because of two problems:

1. spring-test-dbunit depends on Spring 3.0.5, and relies on a method that has since been deprecated and removed in Spring 4.0.0.
2. An inversion of lines in SpringJUnit4ClassRunner.methodBlock() from Spring Test causes many tests to fail from data not being removed after tests are completed.

If preferred, I can close this and open two tickets.

Bug The First

spring-test-dbunit uses a deprecated method in the constructor of ExtendedContextManager:

getTestContext().markApplicationContextDirty();

markApplicationContextDirty() with no arguments was deprecated in release 3.2.2, and removed in release 4.0.0. This line can be replaced with

getTestContext().markApplicationContextDirty(null); // or some other HierarchyMode

As far as I can tell, this is the only breaking API-related change that prevents spring-test-dbunit from using newer versions of Spring.

Bug The Second

Now for the fun part.

spring-test-dbunit relies on version 3.0.5 of Spring Test (and several other projects under the Spring umbrella). All of the tests pass with version 3.0.5 of Spring Test.

When I tried upgrading to Spring 4.0.0, many of the tests failed. I first assumed that this was because I was trying to upgrade across several major releases, but I spent some time trying to find out why the tests were failing. This is my story.

The first thing I did was to try compare the outputs from running the tests for spring-test-dbunit with Spring 3.0.5 and Spring 4.0.0, but ultimately decided that the differences between versions was too great to get anything useful out of diff-ing logs. So I took a step back.

Next, I tried upgrading spring-test-dbunit to use Spring 3.0.6, then tried to diff the logs. I won't post the complete set of logs here, but I will point out what I saw that I thought was important (and might not actually be important, but it helped me find out where the problem came from).

Here's a snippet of the logs from spring-test-dbunit when I run mvn clean verify and depending on Spring 3.0.5: http://pastebin.com/p1JBkUN7

Here's a snippet of the logs from spring-test-dbunit when I run mvn clean verify and depending on Spring 3.0.6: http://pastebin.com/eJ4zCy9y

The short version of the log dumps is that with Spring Test 3.0.5, Spring enables transactions before DBunit starts inserting data into the database. With Spring 3.0.6, Spring enables transactions after DBunit starts inserting data into the database. What I think that means is that the data inserted by DBunit is happening before the transaction starts before each test method, so data gets stuck in the database after each test and many of the tests fail.

So now that I'd pinned the problem down to two specific, consecutive versions of Spring Test, I decided to see what the differences were. The only difference between Spring Test 3.0.5 and Spring 3.0.6 happened in SpringJUnit4ClassRunner.methodBlock().

The commit that makes this change is here: https://github.com/spring-projects/spring-framework/commit/6fc6a9e80ce5119eeb9cdd0d0962e9f989ab10c2#diff-677eaea448b6a1b054564c32524ddf6c

This commit has a ticket reference, which is here: https://jira.springsource.org/browse/SPR-8537

Ultimately, I don't know if this is a bug with spring-test-dbunit or if it's a bug with Spring Test itself. The change is clearly documented by Spring Test as fixing a bug that was instigated by a change in JUnit.

I don't know if this is something that can be fixed elsewhere; I'm not familiar enough with your code base or the Spring Test code base.

Anyway, thanks for the helpful project, and let me know if I can help out in any way!

[philwebb]

I have started version 1.1 on master and decided to drop the @Rule support. The DbUnitTestExecutionListener appears to work with Spring 4.0. Could you try building master and see if it solves your issue.

[fbristow]

I pulled master and everything works wonderfully. Thanks!

When do you expect to be publishing 1.1.0 to maven?

[philwebb]

I want to clear out as many issues as possible, probably a couple of weeks

[philwebb]

I just publish 1.1.0 to maven.

[fbristow]

Super, Thanks!