Jan 21st, 2009, 07:38 AM
Integration testing transactional beans with Propagation.REQUIRES_NEW
We have some Spring bean components that necessarily need to commit their unit of work indepedantly of the larger business transaction.
We mark the service method on these beans with @Transactional(propagation = Propagation.REQUIRES_NEW) to get this behaviour and for the most part everything is working great. Our DBMS (Oracle 9i) does not appear to support NESTED.
Our problem is around making test data available in the DBMS for "integration" JUnit 4 tests for these components. By integration I mean I want to have the Spring application context instantiate and configure the bean to be tested. This is not a "unit" test.
We are moving from JUnit 3 to 4 and switching from AbstractAnnotationAwareTransactionalTests to sub-classing the AbstractTransactionalJUnit4SpringContextTests for these tests.
Because of the propagation strategy declared on the bean, any test data that is created in the test method itself (or a setup method annotated as @Before) is visible in the parent testing transaction, but not the new transaction created by Spring for the target component service method. So our method under test can't see our test data.
FYI, this behaviour all actually makes sense, I am not saying anything is working wrong here.
However in the JUnit 3.8 AbstractAnnotationAwareTransactionalTests superclass we were were using previously we could make this work. We had access to the endTransaction and startNewTransaction methods, which could be used to commit the test data created in the setup, making it visible to the new transaction created for the service method under test. Of course this data also had to be manually cleaned up after the test, but that was ok.
If this all makes sense as a problem, does anyone have any advice on either how to access similar manual transaction control facilities under the AbstractTransactionalJUnit4SpringContextTests testContext framework, or perhaps a better strategy for integration testing these components.
One option would be to test a differently configured version of the bean, with REQUIRES propagation. But part of the reason for this integration test to exercise the actual Spring config and transaction handling.
Last edited by drewcox; Jan 22nd, 2009 at 04:25 AM.
Tags for this Thread