單元測試 - 相同的方法但不同的測試數據

Question

這是關於單元測試的非常基本的問題。

我有一個方法，例如GetOrderDetails，它調用Repository來獲取訂單詳細信息。 我有一個模擬存儲庫，可以設置為返回庫存響應。

為了測試GetOrderDetails方法，我至少會使用以下情況 -

存儲庫調用失敗

1. 帶有錯誤代碼
2. 有一個例外

存儲庫調用成功

1. 返回零結果
2. 返回一個結果
3. 返回了多個結果

我應該編寫一個測試方法來測試上述場景，還是應該為上述每個場景分別采用單獨的測試方法？

我相信，將其分解為多種測試方法至少可以提供以下好處：1。在測試失敗的情況下更高的隔離度2.測試方法中的代碼量少於3.每個測試方法將具有單個存儲庫設置職責，例如設置為無結果，或設置為多個結果等

你可以幫忙看看你對此的看法嗎？

Answer 1

我會為每個案例編寫一個單獨的單元測試。 基本上每次在方法中編寫一個if或者一個switch ，你正在測試它意味着不同的單元測試來處理每個案例。 這樣做的原因是，您的單元測試的安排部分將根據您希望代碼采用的路線（不同的模擬期望，屬性設置，......）而有所不同。 另外，我建議您按以下三個部分組織單元測試：

// arrange
// -> prepare mock objects, properties, setup expectations

// act
// -> invoke the method your are testing

// assert
// -> assert on the results returned by the method your are testing

Answer 2

我知道有些人可能會建立一個基於數據源中不同條件執行的數據驅動測試方法，但我更喜歡單獨的方法，特別是因為這樣我就可以沿着MethodName_StateUnderTest_ExpectedResult （命名約定）給它一個有意義的名稱。由敏捷/單元測試教練和作家Roy Osherove等人倡導）。 我可以查看名稱，並立即知道通過或失敗的原因，不必懷疑可能已經通過或失敗的變體。 它也有助於我的單元測試不依賴於文件系統。

Answer 3

這確實是一個主觀問題，你會得到各種答案。 要記住一些事情。

1. 保持測試代碼簡短而甜蜜。 我嘗試將所有單元測試功能放在一個屏幕上。 如果我能做到這一點，那么我想在那里放任何東西。 只要覆蓋方法很短，我肯定會在特定函數中測試多個東西。

2. 復制代碼單元測試，只有一個變量差異是維護噩夢。 想象一下，有5個單元測試，每個測試包含40行代碼，它們之間的唯一區別是愚蠢的返回值。 如果你這樣做，你會在6個月內摸不着頭腦。

3. 編寫單元測試時使用代碼覆蓋工具。 我不能過分強調這一點。 它將幫助您識別您未測試的區域。 我發現它也有助於我消除死代碼，因為更少的代碼是更少的潛在錯誤。

4. 我在單元測試中使用的最復雜的邏輯是for循環。 這只是為了初始化一個簡單的數組，如果它需要特定於測試的東西。 我總是避免單元測試中的if語句。 但是，如果您正在使用數據驅動測試，那么如果需要，可以使用for循環將數據提供給測試。 但是如果for循環很小，也可以隨意展開循環。

我希望其中一些建議有所幫助。