
Originally Posted by
nilesh
The only thing unusual about this test is that it has multiple calls to the same advised method and in each case an exception is thrown and caught (it expects an exception).
I just tried putting one of these method calls in its own unit test, and it does not exhibit this problem. It only appears when I have more than one calls.
Hi, I have the exact same problem as nilesh when upgrading from Spring 1.1.5 to 1.2.3. I have a Transactional JUnit test that calls a transactionally advised method that returns an expected exception multiple times. For example:
Code:
public class MyTest extends AbstractTransactionalDataSourceSpringContextTests
{
...
public void testSaveClientForVariousExceptions()
{
...
try
{
clientService.saveClient(client); // transactionally advised
fail("should have thrown SomeException");
}
catch (SomeException e)
{
}
...
try
{
clientService.saveClient(client); // second call causes UnexpectedRollbackException
fail("should have thrown SomeOtherException");
}
catch (SomeOtherException e)
{
}
}
...
}
On the second call to the transactionally advised saveClient() method, I get the UnexpectedRollbackException. Like nilesh, my test worked fine with the older version of Spring.
I think I understand Juergen's explanation but I'm wondering how to fix my test? I know one way is to split the test up so that each expected exception is tested in its own test method like so:
Code:
public class MyTest extends AbstractTransactionalDataSourceSpringContextTests
{
...
public void testSaveClientForSomeException()
{
...
try
{
clientService.saveClient(client); // transactionally advised
fail("should have thrown SomeException");
}
catch (SomeException e)
{
}
}
public void testSaveClientForSomeOtherException ()
{
...
try
{
clientService.saveClient(client);
fail("should have thrown SomeOtherException");
}
catch (SomeOtherException e)
{
}
}
...
}
However, I'd rather not do that right now because some of my test methods test many for many exceptions. It would be a lot of work to refactor that right now.
So, I wondering is there another way to fix this? For example, could I override something in AbstractTransactionalDataSourceSpringContextTests? Alternatively, is there something I can call in the catch{} to reset the transaction?