使用EasyMock進行單元測試的良好實施

我對使用EasyMock進行單元測試的良好實現有疑問。使用EasyMock進行單元測試的良好實施

先執行：

Capture<String> capturedString = newCapture(); 
myService.doSomething(capture(capturedString)); 
expectLastCall(); 

assertEquals("stringValue", catpuredString.getValue());

第二個執行：

myService.doSomething("stringValue"); 
expectLastCall();

我感覺舒服的第一個實現，因爲斷言是存在的。但在第二個實現中，我希望「stringValue」傳遞給我的服務。如果不是這種情況，EasyMock將拋出異常。那麼這兩種實現有什麼區別？如果不是，比另一個更好？

謝謝。

來源

2015-08-21 cheb1k4

GreenGiant的回答相當不錯。兩種方式的結果都是相同的，但有不同的感覺。順便說一句，沒有必要添加expectLastCall()。它隱含在void方法中。

要添加到答案：

的期望是你希望發生什麼。你在乎的東西。例如，如果您關心doSomething被調用，但您不關心傳遞的參數，則可以使用any()作爲匹配器。展示你的意圖（你不關心）。如果參數確實重要，則等於匹配器是有意義的。

然後，確實捕捉經常使用，因爲你不太確定會傳遞什麼。例如，如果在對象上沒有定義方法equals()。

當我有複雜的對象檢查時，我傾向於使用捕獲和斷言列表。如果我有一個包含許多字段的bean，那麼更容易獲得一個assert列表，然後使用一個匹配器。

然後，這種方法的缺點是，你不會馬上知道傳遞的參數是無效的。被測試的方法將繼續執行，並可能在之後失敗。所以你永遠不會達到你的斷言，並認爲代碼中的bug比實際情況更遠。

但是被測試的代碼是很好的原子，不是太複雜，這不應該發生太多。

來源

2015-08-22 02:12:11 Henri

我想這只是取決於你是否知道字符串值預先記錄你的模擬電話。

如果您已經知道字符串值，那麼使用第二個實現，因爲它更簡單。
但是，如果您提前不知道，那麼請使用第一個實現。例如，如果傳遞到服務中的值是動態的，並且在實際運行測試之前不知道應該如何。

來源

2015-08-21 17:42:04 GreenGiant

使用EasyMock進行單元測試的良好實施

回答

相關問題