Oliver Drotbohm Archive About Tags

Diggin' into Spring 3 transactional test facilities

May 28th, 2009

Today I devoted my day to a general check in how far Hades can be run with the latest Spring 3 milestone. After managing the typical Maven foo I had a project profile up and running that builds Hades against Spring 3 M3 and executes the tests against it. In case you try to migrate some of your code, too, and wonder where spring-agent JAR has gone: its org.springframework.instrument now. But back to topic.

The build went fine but unfortunately some of my test cases broke when executed under M3. I noticed that things started to get fuzzy with the first test case that was supposed to throw an exception. I have some test cases that look as follows:

@Test(expected=DataAccessException.class)
public void checkDoesNotCascadeIfNotConfigured() {

  // Setup some persistent object graph that is
  // supposed to throw an exception

  userDao.saveAndFlush(user);
}

The key thing to notice here is that I flush the database as the constraint violation I want to expose is only checked at the time the data gets pushed to the database actually. Stepping through the code of Spring testing library in a first level of detail, I realized that the exception is thrown correctly and even detected as the one that is supposed to be thrown. Nevertheless the test method was marked as failed with the exception supposed to be thrown. Furthermore all upcoming tests failed with a duplicate key exception as setting up the test fixture failed right in the beginning. What the heck was going on?

It seemed obvious to me that there would have to be something wrong with the transaction management, so I digged a little further in that direction. Finally I found out this one: in this commit Jürgen Höller added a transactionStatus.flush() during the rollback of a transaction after test execution. This of course raises the exception I wanted to raise a second time but - unfortunately - after the moment the first exception had already been checked to be the expected one. Thus the second exception bubbles up causing the test and the rollback to fail.

As I spoke to Jürgen we found out that the flush was implemented due to a improvement filed in JIRA. Fortunately there is already another ticket that adresses the issue. Waiting for RC1 to see this fixed…

Hades itself seems to be Spring 3 ready already, so if you play around with both of ‘em, I’d be happy to address any issues you face.

blog comments powered by Disqus