Grails的單元測試

這不是一個問題，但也許有關Grails的通用單元測試評論的請求。Grails的單元測試

我一直在反對寫單元測試，除非是非常非常簡單的用例，我總是碰到一些障礙。什麼我發現是隨時隨地的東西需要被嘲笑，像grailsApplication，或者一些其他的框架對象，單元測試開始分崩離析，或者你需要通過它成爲適得其反這麼多跳火圈。然後，在此之上，從1.X到2.X遷移造成的各種單元/集成測試重構的，這從長遠來看，讓事情變得更容易，但在遷移過程中仍造成故障。

我的答案...將所有半複雜的測試移到集成測試中，不要回頭看。它在一切都開始生效時起作用。運行需要更長的時間，但不會長於處理單元測試頭疼的問題。

導致我胃灼熱的最新而非第一個用例試圖單元測試一個服務，該服務創建一個依賴於grailsApplication.config的域對象，並對所述域對象執行某些操作。我嘗試了大多數我發現修復它的東西（除非實際工作正常！），沒有任何工作，我將單元測試代碼移動到集成測試，並在第一次運行時傳遞。單元測試抱怨說'config'無法在空對象或類似的東西上調用，這意味着grailsApplication不在那裏。

我真的沒有看到需要編寫單元測試時，集成測試一直工作的一切，所有的時間。

使用grails 2.2.0。

來源

2013-06-21 emiles

不同意。

單元測試是遵循TDD概念的完美書寫應用程序的基石。進行單元測試的基本原理是將某個模塊與注入隔離，並嘗試使用測試環境提供的所有依賴項來測試它，而不是容器提供的依賴項。

我能理解這裏的痛點。你必須通過一些鍋爐板設置，但這是進行單元測試的主要觀點。

集成測試提供了所有東西（依賴注入在頂部），但這並不能解決在單獨條件下測試模塊的目的。我一直在和從Grails 1.3.4升級到Grails 2.2.0的項目一樣，面臨同樣的問題。但是我花了一些時間來理解最新版本的Grails提供的高度靈活的模擬機制。例如;

@Mock：您不再需要使用mockDomain，註釋將處理單元測試用例中的模擬域類。不要忘記build-test-data plugin使它更方便模擬

@TestFor：您可以使用@TestFor註釋爲grails artefacts（控制器，服務），它會爲你做一些注射，你會最終遵循幾個約定。

不要忘記mixins的威力。

你可以找到更多關於他們here。

現在回答你在單元測試服務類時遇到的問題。 grailsApplication在單元測試用例一應俱全，你沒有必要mock或嘗試從應用程序上下文獲得它。只需在測試類中使用grailsApplication，例如：

//Unit test 
void testSomething(){ 
    assert "Hello" == grailsApplication.config.foo.bar.hello 
} 

//Config.groovy 
foo.bar.hello=hello

不是那麼簡單嗎？切記不要在單元測試類中輸入def grailsApplication。

在另一方面，集成測試是一個更好的辦法，如果你正在測試在特定的服務，或者使用比模塊更多的服務的一部分。

我們做測試，以便通過失敗。編寫一個通過的測試用例會讓我感到不舒服，並認爲我做錯了什麼。 :)

來源

2013-06-21 16:15:32 dmahapatro

感謝您的回覆。雖然我理論上同意你的觀點，但實際上，上述代碼對我的用例並不起作用。也許這是由於grailsApplication.config屬性是一個閉包，而不是簡單的字符串屬性。我使用了TestFor和Mock註釋，並在發佈之前執行了所有提到的操作，但測試仍然拋出了null異常。我嘗試用metaClass覆蓋閉包，結果相同。我沒有注入grailsApplication等 – emiles

我也寫測試，預計會失敗。但是在某個地方，'快樂之路'必須通過！ – emiles

@ emiles你可以使用[pastebin]（http://paste.ubuntu.com/）並顯示測試類嗎？ – dmahapatro

我也忽略大部分單元測試。它對我造成的問題遠遠超過它的價值。但是，我幾乎爲所有部分編寫了集成測試。（雖然不是所有的組合，這是不可能的。）

我測試的主要目的是爲了防止迴歸，大多來自於相關的部分代碼更改。整合測試非常適合我。

來源

2013-06-23 04:42:28 Meam

我都同意和不同意原來的提問者的帖子。我的回答是，單元測試更適合某些事情，但他目前的關鍵點可能不是其中之一。

在我看來，最好的代碼具有極明確的輸入和輸出的簡單行爲地區設有鬆散定義的輸入和輸出複雜的行爲，但地區將有鬆散定義的複雜行爲沒有區域。顯然，配置和輕量級業務邏輯屬於後一類，任何「引擎」代碼都屬於前一類。

原帖引用使用配置，這是通過定義鬆散定義的，所以如果發現邏輯附近有保持相對簡單，它是最好的。任何複雜的行爲可以被抽象爲一般的參數化行爲，並且這種行爲可以被單元測試。但對於涉及配置的功能，集成測試可能會更好。

來源

2013-10-23 17:15:51

Grails的單元測試

回答

相關問題