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