如何做單元測試

Question

我有一個方法CreateTask(UserId)。

對於這種方法，是否足以檢查UserId對null或空和無效值？

或者我應該檢查是否爲特定的UserId創建了Task？

還應該檢查創建的任務數量及其日期和時間嗎？

Answer 1

我不認爲這裏有足夠的信息來回答這個問題。但ti地址的一些要點：

對於這種方法，是否足以檢查UserId null或空和無效的ID？

該方法本身可以在內部做到這一點，但這不是測試的一部分。這只是在運行時進行一些錯誤檢查的方法。這通常被稱爲「防禦性編程」。

或者我應該檢查是否爲指定的UserId創建了Task。

這就是陰天。這就是你想要退一步看看更大的圖景的地方。確保你沒有將你的單元測試與你的實現邏輯緊密結合。測試應該驗證業務邏輯，不知道實現。

這是極有可能「創建任務」不是業務邏輯，而只是一個實現細節。你應該測試的是當執行步驟A時，觀察結果B.系統如何產生結果B基本上是測試內容，但不是直接或明確的。

像這樣保持高級單元測試的一個重要原因是因爲如果實現細節發生變化，那麼您不需要用它們來更改測試。這大大降低了這些測試的價值，因爲它不僅增加了更多的工作，而且還消除了測試作爲這些更改的驗證點，因爲測試本身也更改。測試應該相當簡單和靜態，作爲一組用於驗證代碼的規則。如果測試很複雜並且經常發生變化，那麼他們將失去驗證代碼所需的信任程度。

您不必測試每種方法。您應該測試系統執行的每個可觀察的業務操作。執行這些操作的方法因此得到測試。那些不執行這些操作的方法，首先是否需要這些操作是有問題的。代碼覆蓋工具非常適合於確定這一點。

例如，假設您有MethodA()哪個未被任何測試使用。沒有測試直接調用它，因爲它只是一個實現細節，測試不需要知道它。 （在這種情況下，它甚至可能是有意義的方法是私有的或從外部調用代碼掩蓋一些其他的方式）。這讓你有兩種選擇：

1. 測試是不完整的，因爲需要MethodA()通過未經測試的業務流程。爲該業務流程添加測試。
2. 測試完成，並且MethodA()實際上不是系統所需要的。去掉它。

如果您的測試盲目地測試每種方法，而不考慮業務邏輯的全貌，那麼您永遠無法確定何時系統不需要某些東西。棄用不再需要的代碼是保持簡單且可維護的代碼庫的一個重要組成部分。

Answer 2

1）保持你的方法簡短，所以單元測試將是容易（順便說一句，的原因之一TDD鼓勵良好的設計）

2）檢查所有的邊界條件（輸入無效的，瑣碎的輸入等）

3）檢查所有可能的方案，以實現高覆蓋率（的方式，使TDD容易BTW。一個）（所有可能的執行流過你的方法用簡單的輸入來實現這一點）（順便說一句，原因之一是TDD作品）

4）檢查幾個（也許一個）真實數據典型場景，演示方法

正如你可能已經注意到的典型用法 - 考慮使用TDD這樣你就不必擔心「測試現有的方法」的問題:)