Maven Spring tests fail at startup together, but successfully run individually (ehcache closed, IllegalTransactionStateException)

Question

We use the transaction tests Maven / Surefire and Spring / Hibernate for a fairly large web application. In total, there are 138 Test * classes in which 1,178 tests are performed.

mvn test generate 82 errors, the nature of which implies damage to the application context:

Many of them:

 IllegalTransactionStateException: Pre-bound JDBC Connection found! 

Here is some of them:

 NoSuchMethodError: org.hibernate.cache.CacheException.<init>(Ljava/lang/Exception;)V 

For each failed test, execution of the test class individually mvn test -Dtest=TestFailingClass succeeds. Indeed, using - Dtest=TestClass1,TestClass2,Etc with various subsets of all my test classes successfully or unsuccessfully in different ways. For example, running only failed test classes fails with 0 errors.

With no obvious means to control the order of classes tested by Surefire, it's hard for me to determine which of my test classes seem to leave the context in poor condition.

What I'm looking for is a strategy to help determine what is going on in some deterministic way. Of course, I can see the order in which tests are run from the log, but I cannot reproduce this order in a controlled way.

And of course, suggestions on what to do about it ...

Answer 1

In fact, the problem is due to the corrupt context of the Spring application. One of the early tests pollutes the context and causes the following errors:

One difficulty is trying to control the order of the tests when a test is found that causes problems.

I was able to accomplish this using the Maven log to find the order of execution of the test classes, and then excluding the tests one at a time from the top. Thirty-four tests, I found the culprit.

It was a TestSpringContexts test. Adding @DirtiesContext to these tests solves the problem, but it was also solved by removing calls from the .close () context from the tests.

I wrote a blog post about the process here, but that's the point: http://mojo.whiteoaks.com/2010/04/27/finding-the-test-that-corrupts-the-suite/

Mojo

Answer 2

Without visible tools for managing the order of classes tested by Surefire, it’s hard for me to determine which of my test classes seems to leave the context in poor condition.

Really. And running subsets of tests will give different results (in terms of execution order), which makes it very difficult to debug your problem.

But you could use the patch from SUREFIRE-321 (run the tests in alphabetical order) to get better control (check the comments, one of the posters ran into a very similar problem for you).

Answer 3

Add @Dirtiescontext(classMode = classmode.AFTER_CLASS) in each test case.