優秀單元測試的定義

? 單元測試：一段 自動化 的代碼 ，這段代碼調用被測試的 工作單元 ，之后對這個工作單元的 單個最終結果 的某些假設進行檢驗。單元測試幾乎都是用 單元測試框架進行編寫。單元測試容易編寫，快速運行，可自動化，可靠，可讀，可維護，結果穩定。
　　集成測試：對一個工作單元進行的測試，這個測試對被測試的工作單元沒有完全的控制，并使用該單元的一個或多個真實依賴物，例如數據庫、系統時間、系統文件等
　　工作單元：從調用系統一個公共方法到產生一個測試可見的最終結果，其間這個系統發生的行為。一個工作單元既可以是小到只包含一個方法，也可以大到包含實現某功能的多個類或方法。
　　最終結果：是指被調用的公共方法返回一個值；或者在方法調用前后，系統的狀態或行為有可見的變化，這種變化不需要查詢私有狀態即可判斷；又或者是 調用了一個不受測試控制的第三方系統 ，這個第三方系統不返回任何值，或者返回值已被忽略。

編寫可靠的測試
　　所謂可靠性是指單元測試本身是正確的，即該失敗的時候失敗，該成功的時候成功。只有保證單元測試的可靠性，才能讓開發人員信任該單元測試，不會為了以防萬一進行調試等其他工作。
　　在"單元測試的藝術"中，作者給出了一些簡單的原則和技術幫助編寫可靠的測試。
　　●依據實際情況合理地刪除或修改單元測試
　　如果確定是測試缺陷，而不是產品缺陷（被測試代碼缺陷）時，需要立刻修改相關單元測試代碼；如果被測試的產品代碼的語義或者API變更導致測試失敗，這時是需要修改測試，使用新的語義；如果看到測試名含義不清或者單元測試的可維護性差就應該在保證單元測試基本功能前提下修改測試名稱或者重構測試；如果同一個功能多個單元測試，請刪除重復測試。
　　●避免在單元測試代碼中包含邏輯
　　包含邏輯的測試是指測試代碼中包含switch、if/else、for/while等控制流語句。這樣的測試可讀性差，代碼脆弱，測試代碼的復雜度高，容易包含缺陷，測試結果不容易重現。
　　●每個單元測試只測試一個關注點
　　所謂的一個關注點就是指一個工作單元的一個最終結果：一個返回值、系統狀態的一個改變、對第三方對象的一個調用。測試多個關注點一方面不利于測試命名，另一方面很多單元測試框架中，一個失敗斷言就會拋出一個特殊類型的異常，后面代碼不會繼續執行，這樣不利于收集測試失敗原因。
　　●區分單元測試和集成測試
　　●用代碼審查確保代碼覆蓋率
　　如果你做了代碼審查、測試審查、確保測試優秀而且覆蓋了所有代碼，那么就可以避免犯簡單愚蠢的錯誤，同時也可以從持續的學習中獲益。

編寫可讀的測試
　　單元測試可以看做是一個婉婉道來的故事，這個故事是講給下一代開發者聽，故事的內容就是這個應用程序的組成及其流程。既然是故事，就一定要形象生動，易于理解。那么可讀性就是指如何確保其他開發者能夠理解他們要做的工作，以便維護產品代碼和測試。
　　單元測試的可讀性其實和代碼可讀性在很多方面類似，下面就逐一討論這些方面。
　　●單元測試的命名標準
　　合理地命名測試，主要目的是為了使后來的開發者從為了理解測試而閱讀代碼的負擔中解脫出來。測試名應該包含三部分：被測試方法名、測試場景（即測試使用的條件）、預期行為（即被測試方法的最終結果）。
　　●單元測試中的變量命名規范
　　單元測試除了主要的測試功能之外，它還為API提供某種形式的文檔。通過合理命名變量，幫助閱讀測試的人可以盡快理解你要驗證什么（從而更加理解產品代碼中想要實現什么功能）。
　　●斷言和操作分離
　　●避免濫用setup和teardown
　　比如在setup中準備stub和mock對象，這種情況就會導致閱讀測試的人意識不到測試中使用了模擬對象，也不知道這些模擬對象預期是什么。

編寫可維護的測試
　　可維護性是大多數單元測試面臨的最大挑戰。隨著時間累計，單元測試似乎越來越難維護和理解，被測代碼一個微小的改動，似乎都會使某個測試失敗。那么怎么能夠盡量降低可維護性的成本呢？
　　●只測試公共契約，避免測試私有或者受保護的方法
　　私有方法可以看做是系統內部契約，這個內部契約是動態，在系統重構時可能會被隨時修改，因此針對這些內部契約的單元測試也很可能會失敗。而內部契約最終都會被一個公共契約（公共方法、整體功能）所調用，也就是說任何私有方法通常都是一個更大的工作單元的一部分。
　　●去除重復代碼
　　可以使用輔助方法或者setup來去除重復代碼的問題
　　●實施測試隔離
　　測試隔離是指每個測試都只生活在自己的小世界中，它與其他測試之間沒有任何依賴關系，甚至不知道其他測試存在。
　　下面列舉幾種常見的測試隔離的反模式。
　　1、測試結果依賴測試執行的順序
　　2、測試調用其他測試方法
　　3、測試中使用的共享資源（內存或外部資源）沒有得到清理或回滾
　　●避免對不同關注點多次斷言，盡量使用參數化測試或者對每個關注點設計單獨的測試用例
　　●避免過度指定
　　常見的過度指定的例子。
　　1.對系統內部契約進行斷言
　　2.使用過多的模擬對象
　　3.精確匹配

轉載：http://www.51testing.com/html/72/n-3721672.html

總結

以上是生活随笔為你收集整理的如何编写优秀的单元测试用例的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。