我们正在为一个相当大的Web应用程序使用Maven / Surefire和Spring / Hibernate事务测试。有138个Test *类，总共运行了1178个测试。
直截了当的mvn test会产生82个错误，其性质往往意味着损坏的应用程序上下文：
其中许多：
IllegalTransactionStateException: Pre-bound JDBC Connection found!
其中一些：
NoSuchMethodError: org.hibernate.cache.CacheException.<init>(Ljava/lang/Exception;)V
对于每次失败的测试，单独运行测试类mvn test -Dtest=TestFailingClass都会成功。实际上，使用 - Dtest=TestClass1,TestClass2,Etc与我的所有测试类的各种子集成功或以不同方式失败。例如，仅运行失败的测试类成功，出现0错误。
由于没有明显的方法来控制Surefire测试的类的顺序，我很难确定哪些测试类似乎让上下文处于错误状态。
我正在寻找的是一种帮助确定以某种确定性方式发生的事情的策略。我当然可以看到测试的顺序是从日志中运行的，但我无法控制地重现该命令。
当然，有关该怎么做的建议......
答案 0 :(得分：2)
实际上，问题来自于损坏的Spring应用程序上下文。早期测试之一是弄脏上下文并导致以下测试错误。
一个难点是试图在发现导致问题的测试时控制测试的顺序。
我能够通过使用Maven的日志来查找运行的测试类的顺序，然后从顶部一次排除一个测试。三十四次考试中，我找到了罪魁祸首。
这是一个名为TestSpringContexts的测试。将@DirtiesContext添加到这些测试可以解决问题，但也可以通过从测试中删除对context.close（）的调用来解决。
我在这里写了一篇关于这个过程的博客文章，但这就是问题的要点：http://mojo.whiteoaks.com/2010/04/27/finding-the-test-that-corrupts-the-suite/
Mojo
答案 1 :(得分：1)
由于没有明显的方法来控制Surefire测试的类的顺序，我很难确定哪些测试类似乎让上下文处于错误状态。
事实上。并且运行测试的子集将产生不同的结果（从执行顺序的角度来看），这使得调试问题非常困难。
但你可以使用SUREFIRE-321的补丁（按字母顺序运行测试）来获得更好的控制（查看评论，其中一张海报面临着一个非常类似的问题你的）。
答案 2 :(得分：0)
在每个测试用例上添加@Dirtiescontext(classMode = classmode.AFTER_CLASS)。