集成與單元測試

Question

我正在用Grails進行開發。由於框架將引導數據並完全刷新彈出上下文，因此我發現我爲服務編寫了很多集成測試。讓我重述一下：我發現我沒有寫服務的單元測試，只有集成測試。這是一個壞主意嗎？我看到的唯一不足就是我的測試需要更長的時間才能運行。

我在控制器上使用單元測試，如在控制器中測試各種應用程序流程，結果類型，重定向邏輯等。但我寫的大多數測試都是集成測試。這似乎與傳統的J2EE測試有所不同，大部分是單元測試。

編輯 - 要清楚，我不寫集成測試，因爲代碼是如此複雜，只有集成測試才能做到。我編寫集成測試，因爲它更容易測試一切，因爲框架給你很多。我嘲笑某些事情，比如如果一個服務與acegi authenticationService協作，我嘲笑它。我也會模擬任何時候我們與web服務進行交互，因爲你必須爲了得到一個沒有特殊設置的測試。

Answer 1

我清楚地看到了更多功能測試和更少的單元測試的趨勢，特別是對於邏輯低的重度連接組件。如果我在一個特定的類中實現一個複雜的算法，我通常會爲它編寫單元測試，但是如果複雜性是由於與其他組件集成在一起（這很常見），單元測試並不值得花費麻煩。

Answer 2

您可能能夠使用模擬框架來隔離服務的不同部分以進行單獨測試。不要依賴龐大的Spring上下文，直接實例化你的服務類並填充與mock測試無關的依賴關係。您可能需要進行一些重構來解耦您的依賴關係，但它通常會是最好的。這可能會導致編寫更多更小的測試，而不是依靠幾個大型集成測試。

我處於類似的情況，許多已建立的測試都是真正的集成測試，並且可能很難但並非不可能改變這種未來。

Answer 3

一般來說，重要的措施是代碼覆蓋率。

如果全局接口更穩定（不易改變），那麼可以進行集成測試。

Answer 4

您應該儘快測試，因爲您希望儘快顯示錯誤，理想情況下我們的代碼仍在您自己的控制之下。後來發現的錯誤是糾正的成本越高。

如果您公開的是非平凡的邏輯，您應該使用單元測試測試主決策路徑的邏輯，以及集成測試中該邏輯的暴露以及與外部依賴關係的交互。

如果您是一位獨立開發人員或在一個小團隊中工作，有時很難看到單元測試和集成測試之間的區別。如果您處於多個團隊正在開發單一產品的環境中，則假設您的代碼中的邏輯已經過驗證（單元測試），現在您想了解這些模塊相互之間如何進行互操作（集成測試） 。

這不是一個很好的模式，因爲您將測試推遲到項目或開發環境的後期階段，遲早會發現一次發現錯誤代碼已經離開了你的桌子。這意味着在解決您之前和之前應該發現的某些問題的同時，可能會阻止整個產品發佈以及可能的產品發佈。