自動化單元測試建議

本文只是一些您在創建單元測試時可以采納的基本建議。

設計彼此獨立的單元測試，其中它們可以獨立運行（由于可以通過測試 UI 隨意選擇或取消選定它們）。

不要只進行正面測試。請確保代碼能夠響應任何方案，包括發生意外時（資源不可用，數據庫只讀等）。

把自己當作一個 QA 人員，想象成一個測試人員，而不僅僅是一個開發人員。您花在設計單元測試上的時間將有助于減少日后解決故障所用的時間。請注意對象的幾個小細節：數據如何在對象之間傳輸？誰使用它們？銷毀對象容易嗎？如果我“進行此操作”，將會發生什么？

跳出您自己的思維模式。盡可能多地對測試進行頭腦風暴。當您完成時，回頭查看您可能漏掉的內容。來自團隊成員的請求反饋 — 例如，他們創建了什么其他類型的測試？其他人可能提供一個對熟悉自己代碼的開發人員而言非常困難的觀點。

代碼覆蓋。使用 VSTS 代碼覆蓋規范提供有關每個測試運行中實際執行多少代碼的信息（代碼的行數，占所有代碼的百分比）。如果編碼完成，并且通過了所有測試，但代碼覆蓋顯示只執行了該邏輯的一小部分，那么您的測試真的成功了嗎？高代碼覆蓋不一定意味著您具有一個完整的“測試”集，而未覆蓋的代碼通常非常適用于一個新的測試用例。

當生成單元測試時，要幫助其他人了解您的代碼：

使用一個項目結構，該結構映射所測試程序集的結構。

每個程序集有一個相關的測試程序集。

每個類有一個相關的測試類。

在各自的測試方法中包含每個方法名（即，Load() 將有 PositiveLoadTest()、NegativeLoadTest()、PositiveScalarLoadTest() 等的測試方法）。

使用一致的命名協定，包括對象的屬性和方法名。

此外，當其他所有測試都失敗時，請進行調試。自動化單元測試應該有助于減少您用在調試器上的時間。但是，如果測試結果和代碼覆蓋無法提供測試失敗的原因，那么您大可不必擔心調試單元測試。從 Beta 2 版的 Visual Studio 2005 Team System 開始，開發人員可以使用 Test Manager 中的 Debug checked tests 選項調試他們的單元測試程序集。

原文轉自：http://www.anti-gravitydesign.com