單元測試指南

Question

有誰知道在哪里可以找到單元測試指南和建議？ 我想要一些解決以下類型主題的東西（例如）：

• 測試應該與應用程序邏輯在同一個項目中嗎？
• 我應該有測試類來鏡像我的邏輯類，還是應該只有我認為需要的測試類？
• 我應該如何命名我的測試類，方法和項目（如果他們進入不同的項目）
• 是應該測試私有，受保護和內部方法，還是只測試可公開訪問的方法？
• 單元和集成測試應該分開嗎？
• 是否有充分的理由不進行100％的測試覆蓋？

我不應該問我應該怎么做？

在線資源最好。

Answer 1

我會推薦Kent Beck關於TDD 的書。

此外，你需要去Martin Fowler的網站。 他也有很多關於測試的好信息。

我們在TDD上非常重要，所以我將從這個角度回答這些問題。

測試應該與應用程序邏輯在同一個項目中嗎？

通常我們將測試保存在同一個解決方案中，但我們將測試分解為單獨的DLL /項目，這些DLL /項目鏡像他們正在測試的DLL /項目，但是維護命名空間，測試位於子命名空間中。 示例：Common / Common.Tests

我應該有測試類來鏡像我的邏輯類，還是應該只有我認為需要的測試類？

是的，應該在創建任何類之前創建測試，並且根據定義，您應該僅隔離測試單個單元。 因此，您應該為解決方案中的每個類設置一個測試類。

我應該如何命名我的測試類，方法和項目（如果他們進入不同的項目）

我想強調行為是正在測試的，所以我通常在SUT之后命名測試類。 例如，如果我有一個User類，我會將測試類命名為：

public class UserBehavior

應該命名方法來描述您期望的行為。

public void ShouldBeAbleToSetUserFirstName()

可以根據需要命名項目，但通常您希望項目正在測試哪個項目。 請參閱有關項目組織的先前答案

是應該測試私有，受保護和內部方法，還是只測試可公開訪問的方法？

您再次希望測試斷言預期的行為，就像您是被測對象的第三方使用者一樣。 如果您測試內部實現細節，那么您的測試將是脆弱的。 您希望測試為您提供重構的自由，而不必擔心破壞現有功能。 如果您的測試了解實施細節，那么如果這些細節發生變化，您將不得不更改測試。

單元和集成測試應該分開嗎？

是的，單元測試需要與驗收和集成測試隔離開來。 關注點的分離也適用於測試。

是否有充分的理由不進行100％的測試覆蓋？

我不會掛掉100％的代碼覆蓋率。 100％的代碼覆蓋率往往意味着測試中的某種程度的質量，但這是一個神話。 你可以進行可怕的測試，但仍能獲得100％的覆蓋率。 我寧願依靠良好的Test First心態。 如果您在編寫一行代碼之前總是編寫測試，那么您將確保100％的覆蓋率，因此它變得沒有實際意義。

一般來說，如果你專注於描述課程的完整行為范圍，那么你將無需擔心。 如果你將代碼覆蓋率作為度量標准，那么懶惰的程序員只會做足夠的事情來滿足那個標記，你仍然會有糟糕的測試。 相反，在很大程度上依賴同行評審，同時評估測試。

Answer 2

這是一個很好的問題。 我們有機地發展了自己，我懷疑最好的方法就是這樣。 那里有一點“它取決於......”。

我們在同一個項目中，在名為“UnitTes”的子命名空間中進行測試

我們的測試類反映了邏輯類，以簡化跟蹤測試與測試內容的關系

類被命名為它們正在測試的邏輯類，方法是根據它們正在測試的場景命名的。

我們只為公共和內部方法編寫測試（測試在同一個項目中），並且目標是95％的課程覆蓋率。

我不想區分“單位”和“整合”。 要花很多時間來弄清楚哪個是哪個......包包那個！ 測試是一項測試。

100％太難以實現。 我們的目標是95％。 獲得最終5％所花費的時間以及它實際捕獲的內容的回報也在遞減。

這就是我們以及適合環境和節奏的因素。 你的milage可能會有所不同。 想想你的環境和所涉及的個性。

我期待着看到別人對這個問題的看法！

Answer 3

Josh的回答是正確的 - 只有一點澄清：

我將單元測試與集成和驗收測試分開的原因是速度。 我使用TDD。 我需要接近關於我剛創建/修改的代碼行的即時反饋。 如果我正在運行完整的集成和/或驗收測試套件，那么我無法理解這一點 - 測試可以實現真正的磁盤，真正的網絡以及真正緩慢且不可預測的外部系統。

不要穿過橫梁。 如果你這樣做會發生壞事。

Answer 4

我一直建議你閱讀測試驅動開發：通過示例和測試驅動開發：實用指南這對單個主題來說太多問題了

Answer 5

為了：

• 不，通常最好將它們包含在一個單獨的項目中; 除非您希望能夠在運行時運行診斷程序。
• 理想的是100％的代碼覆蓋率，這意味着每個類中的每個例程中的每行代碼。
• 我使用ClassnameTest，ClassnameTest.MethodNameTestnumber
• 一切。
• 我會說是的，因為如果單元測試失敗，則不需要運行集成測試。
• 只需設置和獲取字段的簡單屬性不需要進行測試。

Answer 6

關於你的最后一個問題，根據我的經驗，不堅持100％測試覆蓋率的“好”原因是需要花費不成比例的努力來獲得最后幾個百分點，特別是在更大的代碼庫中。 因此，一旦達到收益遞減點，就決定是否值得花時間。

Answer 7

測試應該與應用程序邏輯在同一個項目中嗎？

這取決於。 無論哪種方式都有取舍。

將它保存在一個項目中需要額外的帶寬來分配項目，額外的構建時間並增加安裝占用空間，並且更容易犯錯誤，即擁有依賴於測試代碼的生產邏輯。

另一方面，保持單獨的項目可能會使編寫涉及私有方法/類的測試（取決於編程語言）變得更加困難，並導致輕微的管理麻煩，例如建立新的開發環境（例如，當新的開發人員加入項目）更難。

這些不同成本的重要程度因項目而異，因此沒有普遍的答案。

我應該有測試類來鏡像我的邏輯類，還是應該只有我認為需要的測試類？

沒有。

您應該擁有允許良好分解的測試代碼的測試類（即最小的重復，明確的意圖等）。

直接鏡像測試類中的邏輯類的明顯優勢在於，它可以輕松找到與特定代碼段相對應的測試。 在不限制測試代碼的靈活性的情況下，還有其他方法可以解決此問題。 測試模塊和類的簡單命名約定通常就足夠了。

我應該如何命名我的測試類，方法和項目（如果他們進入不同的項目）

您應該將它們命名為：

• 每個測試類和測試方法都有明確的目的，並且
• 因此，某人正在尋找特定的測試（或測試特定單元）可以輕松找到它。

是應該測試私有，受保護和內部方法，還是只測試可公開訪問的方法？

通常應該測試非公開方法。 這取決於您是否從僅測試公共接口獲得足夠的信心，或者您真正想要測試的單元是否不可公開訪問。

單元和集成測試應該分開嗎？

這取決於您選擇的測試框架。 做哪個最適合您的測試框架並使其成為：

• 與一段代碼相關的單元和集成測試都很容易找到，
• 只運行單元測試很容易
• 只運行集成測試很容易，
• 它很容易運行所有測試。

是否有充分的理由不進行100％的測試覆蓋？

是的，有充分的理由。 嚴格來說，“100％測試覆蓋率”意味着您的代碼中的每種可能情況都會得到鍛煉和測試。 這幾乎對任何項目來說都是不切實際的。

如果您只是采用“100％測試覆蓋率”來表示測試套件在某個時刻執行了每一行源代碼，那么這是一個很好的目標，但有時在尷尬的地方只有幾行很難達到自動化測試。 如果定期手動驗證該功能的成本低於通過扭曲達到最后五行的成本，那么這是不具有100％線路覆蓋率的充分理由。

而不是一個簡單的規則，你應該有100％的線覆蓋率，鼓勵你的開發人員發現你的測試中的任何差距，並找到解決這些差距的方法，無論是否“覆蓋”的行數改善。 換句話說，如果你測量覆蓋的線條，那么你將改善你的線覆蓋 - 但你真正想要的是提高質量。 因此，不要忘記線路覆蓋范圍只是質量的粗略近似。