我们正在编写我们的Grails 2.0.0应用程序的集成测试，并在Fixtures和Buid-Test-Data插件的帮助下完成。Grails集成测试以（看似）随机且不可重复的方式失败
在测试过程中，发现集成测试在某些时候失败，并在其他时间通过。运行'测试应用程序'有时会导致所有测试通过，有时会导致我们的一些测试失败。
当测试失败时，它们是由插入域类实例期间违反的唯一约束引起的。这将表明测试数据库中仍有记录。我正在运行H2数据库，并且在我的DataSource.groovy中肯定有'dbCreate =“create-drop”'。
Grails 2.0 integration test pollution?似乎表明在Grails中存在严重的测试污染问题。有没有解决这个问题的方法？我打了Grails-8530？
[编辑]测试污染似乎是由单元测试引起的。我们通过删除单元测试并反复成功运行'test-app'来证明这一点。
当我遇到这样的错误时，我喜欢尝试找到导致问题的单元测试。这可能有点棘手，因为你们似乎偶尔会失败。
1）我会看看最近添加的单元测试。如果这个问题刚刚开始发生，那么这是一个好地方。
2）Metaclassing似乎很擅长导致这些类型的错误，所以我会寻找元类，而不是正确设置/拆除。 2.0的问题与< = 1.3.7不一样，但可能是问题所在。
3）我写了一个插件，以随机顺序执行您的测试。这可能无助于解决当前的问题。但是什么可以帮助你打印出你所有的测试，以便你可以把它给你并且运行grails test-app <pasted list of unit tests> IntegrationTestThatIsFailing然后开始移除单元测试以找到罪魁祸首。 （http://grails.org/plugin/random-test-order）。我在2.0中发现了一个bug，我还没有时间修复（集成测试在渲染视图名称上声明时失败），但它仍然应该为您打印测试名称（这比自己做得更好:)
事实上，集成测试因违反约束而失败，这是由于现有记录让我想起了曾经遇到过的功能测试（硒）以不可预知的顺序执行的情况，其中一些情况并未正确清理数据库。当然，功能测试的情况是不同的，因为恢复数据库状态更加困难（测试用例不能在另一个jvm中回滚事务）。
虽然集成测试通常会回滚事务，但如果您的代码显式控制事务（提交），则仍然可以中断此行为。
首先，我会尝试强制执行命令，如3）中Jarred所述。假设你可以重现行为，接下来我会检查事务行为。将org.hibernate.transaction的日志记录级别设置为调试将显示事务边界在哪里。
对不起，还没有一个很好的解释为什么消灭单元测试有助于摆脱的症状除了一般的“可能metaclassing问题”。 :)