Grails集成測試以（看似）隨機和不可重復的方式失敗

Question

我們在Fixtures和Buid-Test-Data插件的幫助下為Grails 2.0.0應用程序編寫集成測試。

在測試期間，發現集成測試在某些時間失敗，並在其他時間通過。 運行'test-app'有時會導致所有測試通過，有時會導致我們的某些測試失敗。

當測試失敗時，它們是由插入域類實例期間違反唯一約束引起的。 這表明測試數據庫中仍有記錄。 我正在運行H2 db，並且在我的DataSource.groovy中肯定有'dbCreate =“create-drop”'。

Grails 2.0集成測試污染？ 似乎表明Grails存在嚴重的測試污染問題。 這有什么解決方案嗎？ 我打過Grails-8530嗎？

[編輯]測試污染似乎是由單元測試引起的。 我們通過刪除單元測試並反復成功運行'test-app'來證明這一點。

Answer 1

當我遇到這樣的錯誤時，我喜歡嘗試找到導致問題的單元測試。 這可能有點棘手，因為你的情況似乎只是失敗了。

1）我會看一下最近添加的單元測試。 如果這個問題剛剛開始發生，那么這是一個值得關注的好地方。

2）Metaclassing似乎擅長引起這些類型的錯誤，所以我會尋找沒有正確設置/拆除的元類。 與<= 1.3.7一樣，2.0不是問題，但可能是問題。

3）我寫了一個以隨機順序執行測試的插件。 這可能無法幫助您解決當前的問題。 但是可能對你有幫助的是它打印出你所有的測試，所以你可以拿它給你的東西並運行grails test-app <pasted list of unit tests> IntegrationTestThatIsFailing然后開始刪除單元測試以找到罪魁禍首。 （ http://grails.org/plugin/random-test-order ）。 我在2.0中發現了一個我沒有時間修復的錯誤（集成測試在渲染視圖名稱時斷言）但它仍然應該為你打印出你的測試名稱（這比自己做的要好:)

Answer 2

事實集成測試由於現有記錄而導致約束違規失敗，這讓我想起了曾經遇到的功能測試（selenium）以不可預測的順序執行的情況，其中一些沒有正確清理數據庫。 當然，功能測試的情況是不同的，因為恢復數據庫狀態更加困難（測試用例無法在另一個jvm中回滾事務）。

盡管集成測試通常會回滾事務，但如果您的代碼明確地控制事務（提交），仍然可能會破壞此行為。

首先，我會嘗試強制執行命令，正如Jarred在3）中提到的那樣。 假設您可以重現行為，接下來我會檢查事務行為。 將org.hibernate.transaction的日志記錄級別設置為debug將顯示事務邊界的位置。

對不起，還沒有一個很好的解釋為什么除了一般的“可能的元類分類問題”之外，消除單元測試有助於擺脫症狀。 :)