An attempt to use @ExpectedDatabase annotation brought unexpected results when assertion fails:
transaction is not committed/rolled back;
database connection stays open and is not released back to the pool;
subsequent test has a good chance to get stuck waiting for the DB lock.
An offender seemed to be the org.dbunit.Assertion.assertEquals(...) methods, which throws java.lang.Error instead of promised org.dbunit.DatabaseUnitException when the assertion fails.
In a org.springframework.test.context.TestContextManager.afterTestMethod(...) CALL to the configured test execution listeners is, naturally, surrounded by try/catch block that intercepts java.lang.Exception. Unfortunately, when the listener throws a java.lang.Error instead, it escapes into surrounding org.springframework.test.context.junit4.statements.RunAfterTestMethodCallbacks.evaluate() method, preventing the "downstream" listeners from being executed. One of the skipped listeners is, obviously, a TransactionalTestExecutionListener, responsible for ending a current transaction.
An attempt to use
@ExpectedDatabase
annotation brought unexpected results when assertion fails:An offender seemed to be the
org.dbunit.Assertion.assertEquals(...)
methods, which throwsjava.lang.Error
instead of promisedorg.dbunit.DatabaseUnitException
when the assertion fails.The assertion is invoked by
In a
org.springframework.test.context.TestContextManager.afterTestMethod(...)
CALL to the configured test execution listeners is, naturally, surrounded by try/catch block that interceptsjava.lang.Exception
. Unfortunately, when the listener throws ajava.lang.Error instead
, it escapes into surroundingorg.springframework.test.context.junit4.statements.RunAfterTestMethodCallbacks.evaluate()
method, preventing the "downstream" listeners from being executed. One of the skipped listeners is, obviously, aTransactionalTestExecutionListener
, responsible for ending a current transaction.Filed similar issues with:
An easy workaround would be to use a DbUnitTestExecutionListener "extention":