Testing transaction behaviour

Hi. We are migrating (in small steps) from our struts, J2EE, CMP architecture to a struts, Spring, Hibernate architecture. We'll probably move off struts as well, but baby steps....

We are writing suites of tests for the objects we write. We have
1) A set of tests that exercise Hibernate outside of anything else
2) A set of tests that exercise out service layer, which includes Spring. We use a MockDao to pretend that Hibernate is doing its thing.
3) A set of tests that exercise our struts layer.

Each of these is intended to be independant, so that we can isolate tests to specific areas. The problem I am encountering is in the service layer.

When writing part of the application, I noticed that even though we threw an Exception, the data was still being committed. I discovered that Spring will only rollback by default on a RuntimeException whereas ours were checked exceptions. We configured the spring transaction definition by putting -OurExceptionClass in the definition.

All good. But in order to be complete we should be testing that when certain exceptions are thrown, that Spring marks the transaction for rollback. However I can't find a way of performing this check.

In our service test we call the actual service class, so Spring should be doing its transaction thing, but by the time we get back to the test class, the service method and so presumably the transaction is over. How do I get hold of the Spring TransactionDefinition that was used in order to interrogate it?

No I can't just go and load the data again to see that no udates were made, because we are using a MockDao. My test initially passed, and it was only because I happened to go check during the struts tesing later on that I noticed that the data had been commited when it shouldn't have.

Thanks, Andrew