集成測試，單元測試和代碼覆蓋

Question

我正在為一位同事審查一些代碼，並在單元測試類中遇到了一個測試，它看起來像這樣：

// setup
Foo f = ...
FooToBarConverter ftb = ...
Bar b = ftb.Convert(f); // It is easier to create a Bar by converting it from a Foo than making one 'from scratch'

// test
systemUnderTest.DoSomething(bar);

// assert
Assert.IsTrue(...)

很明顯，這是一個集成測試，因為它正在測試FooToBarConverter以及被測系統，因為它是唯一涵蓋DoSomething（）方法的測試。 我建議將此測試移至集成測試解決方案，但這會降低單元測試的代碼覆蓋率。 我們的目標是100％的單元測試代碼覆蓋率（是的 - 我知道100％的覆蓋率是達到目的的手段而非終端本身，100％覆蓋的代碼不一定是100％正確的代碼）。

如果我們將集成測試移出去，是否有理由創建單元測試以恢復覆蓋范圍？

或者我們是否針對100％單元測試覆蓋率的錯誤做法？ 我們是否應該通過組合所有測試（甚至100％的目標）來實現100％的覆蓋率？

謝謝。

編輯/ UPDATE：

這不是關於如何正確地測試被測系統的問題（我知道這不是單元測試的原因，我知道如何正確地將其轉換為單元測試），也不是關於覆蓋范圍的問題FooToBarConverter。 我希望對被測系統的代碼覆蓋率有所了解：對被測系統的集成測試是否足夠？ 還是應該進行單元測試？

Answer 1

我認為這里的答案是“它取決於”。

• 如果你在FooToBarConverter類上有完整的單元測試覆蓋率，那么你可能只需要使用systemUnderTest的集成測試，因為你可以放心地說真正的FooToBarConverter在這種情況下表現得如預期，因此不會錯誤地影響測試結果。

• 在另一方面，目前還不清楚具體是什么，這個測試是檢查-你檢查的行為systemUnderTest給予有效時FooToBarConverter ，或在一些其他預期的副作用systemUnderTest到FooToBarConverter是純屬巧合演員？ （即你確定這不是對bar的間接測試嗎？）

現在，我個人建議你也做了適當的，“純”單元測試（使用模擬或存根FooToBarConverter的） systemUnderTest因為

• 它會使回歸更容易管理; 假設將來對FooToBarConverter某些更改會使其單元測試失敗 - 因此很可能也會使此集成測試失敗。 對於那些查看失敗測試並且不知道可以忽略集成測試失敗並且只需要修復FooToBarConverter測試的人來說，這可能會令人困惑。 我知道這是一件小事，但有一天可能會節省5分鍾:)

• 如何測試負面情況（當給出一個破壞/無效/ null FooToBarConverter時， systemUnderTest行為）？ 既然你可能不得不為這種情況編寫帶有存根/模擬的單元測試，你也可以在同一個項目/測試類中對好的情況進行單元測試，它更清晰 - 否則你有聚合單元測試和集成測試項目的代碼覆蓋率，以驗證systemUnderTest是否完全覆蓋...

此外，不要擔心100％的代碼覆蓋率; 這很好，但在實踐中很少見到它。 我並不是說這對於良好的設計實踐來說也是如此; 簡單的現實是，沒有任何設計是100％完美的，因此可以預期有時候你沒有時間/資源/意願來重構你的類以允許每個單獨的依賴注入，或者是能夠為每個縫間交互等使用接口

希望有所幫助。