單元測試類VS方法

Question

單元測試時，測試類或單個方法是否更好？

大部分我見過的例子，除了從其他類中測試類之外，嘲笑類之間的依賴關係。我玩過的另一種方法是你沒有測試的模擬方法（通過覆蓋），這樣你只用一種方法測試代碼。因此，1個錯誤會破壞1個測試，因爲這些方法是相互隔離的。

我想知道是否有一個標準方法，以及是否存在隔離每個測試方法而不是隔離類的大缺點。

Answer 1

短語單元測試來自硬件系統測試，應用於軟件時或多或少無語義。它可以用於從單個例程的隔離測試到使用內存數據庫在無頭模式下測試完整系統的任何事情。

所以，不要相信任何人認爲定義意味着只有一種方法可以獨立於上下文來做事情;有多種方式，其中一些有時比其他更有用。大概每個聰明人會爭辯的方法都至少有某種價值。

硬件的最小單位是原子或可能是一些亞原子粒子。有些人測試軟件就像他們在掃描每個原子，看看量子力學的定律是否仍然存在。其他人採取戰艦和see if it floats。

之間的東西很可能會更好。一旦你知道你正在生產的東西超越'軟件'，你就可以開始制定一個適合你應該做的計劃。

Answer 2

單元測試的重點是測試一個代碼單元，即類。

這會讓您確信其一部分代碼正在做預期的工作。

這也是測試過程的第一部分。它有助於儘早捕捉那些煩人的bug，並通過單元測試來證明它更容易解決問題。

Answer 3

可能沒有人標準答案。單元測試是爲開發人員（或者他們應該做的），做對你最有幫助的事情。

測試個別方法的一個缺點是您可能無法測試對象的實際行爲。如果嘲笑某些方法不準確，可能無法檢測到。另外嘲笑是很多工作，並且他們傾向於使測試非常脆弱，因爲它們使得測試關心很多具體的方法調用發生。

在我自己的代碼中，我嘗試儘可能將基礎結構類型的依賴關係與業務邏輯分開，以便我可以完全編寫業務邏輯類的測試而不會模擬。如果你有一個令人討厭的遺留代碼庫，那麼測試單個方法和模擬對象的任何協作方法可能更有意義，以便將這些部分彼此隔離。

理論上，物體應該是有凝聚力的，所以對它們進行整體測試是有意義的。在實踐中，很多事情並不特別面向對象。在某些情況下，模擬協作者方法比模擬由協作者調用的注入依賴關係更容易。

Answer 4

根據定義進行單元測試是測試您可以編寫的最小的一段代碼。 「單位」不是他們是方法的類。

每個公共方法應該至少有一個單元測試，專門測試該方法。

如果你按照上面的規則，你最終會到達課堂互動的覆蓋範圍。只要你爲每種方法寫1次測試，你也會覆蓋課堂互動。