好的實踐要求開發人員文檔化它們的測試，并且對那些測試進行同行評審以確保有適當的覆蓋率。如果使用自動化測試，那么開發人員能簡單地為開發工具創建測試腳本，并且提交那些腳本用于評審。
當然，對于什么應該包括在單元測試中必須建立一個小組的標準。作為一個開發組，關于應該做什么測試要達成一致的共識需要花費一些時間和做出一些權衡，但是花在這里的時間會從正確的構建過程中得到加倍的回報！讓我們看看一些單元測試期望的例子。
功能
當然，每個模塊必須被測試以確保它滿足設計的要求，并且確保它做了真正應該做的正確的事情。它應該處理什么樣的輸入？必須完成什么工作？會提供什么服務？它應該產生怎樣的輸出？它必須管理什么數據,應該怎樣使用那些數據？我們必須確保這個模塊真正做了它需要做的事情。
負面測試
然后是錯誤處理。當出現錯誤時這個模塊會做“正確”的事情嗎？當它處理某些特殊的輸入時會出現什么情況？缺乏數據組成或數據輸入的順序被打亂的時候會怎樣？當需要輸入數值數據時給它非數值數據會怎樣？數據溢出？如果它接收到一個從數據庫或網路接口返回的錯誤狀態時會怎樣？它會如何處理？一個模塊在被認為完成之前，必須正確地處理所有錯誤條件。
覆蓋
我們都知道完全的測試不是軟件測試的一個合理目標。太多的輸入組合，事件的發生有太多的可能順序，太多不同的出錯方式，因此完整地測試所有東西，即使是一個很小的程序，也是不可能的。
但是代碼和路徑覆蓋是單元測試可達到的一個目標。事實上，單元測試階段是把完整覆蓋代碼和路徑作為一個合理的目標的唯一時間。
- 代碼覆蓋
在單元測試過程中，要求代碼的每一行都被執行到，這一點都不過分（并且有很多分析工具可以幫助我們確保這點）。一些代碼（尤其是錯誤處理）是不能被測試到的，除非采用額外的步驟（例如編寫一個傳遞壞數據的函數，或者把錯誤代碼注入到內存中），但是這些不僅僅是適合做的，而且對于確保程序可以處理各種應該處理的情況來說非常關鍵的！
- 路徑覆蓋
除了代碼行覆蓋，測試代碼的每一個路徑也是非常合理的。例如，我們可以確保每一個“if”的分支都經過了，并且確保每一個“case”的所有分支都得到了執行。我們還可以確保每一個循環路徑的初始化和終止條件都是正確的。
回歸測試
這些都是“新鮮出爐”的代碼應該測試的內容，但是如果改變了一點點的代碼模塊應該做多少測試呢？在單元級別，應該做多少回歸測試呢？這是很容易誤解的地方：因為只是很小的改變，所以不值得花費很多的時間去測試它。
確實，對于每次一小行的代碼的改變我們不能進行完整的測試。但是，同時，這些“很小”的改動通常帶來潛在的、重大的、非預期的影響。最好的方法是恰當地評估回歸測試：結合基于風險的測試和區域影響測試。
基于風險的測試
基于風險的測試指基于缺陷的風險來選擇測試。對于風險有兩個方面：可能性和影響程度。
可能性是判斷更改會造成某些問題的機會。我們應該測試那些可能出現問題的地方。評估代碼改變的地方是其中一個判斷的方式，另外一個是尋找曾經出現的類似改變。
影響程度是關于程序出現錯誤時造成的損失程度（不管出現的可能性）。那些高影響程度的地方應該被重現測試。例如，程序經常被使用到的核心功能、影響安全的地方。
區域影響測試
區域影響測試是指專注于發生改變的代碼區域的測試。例如：
- 一個開發人員應該完全覆蓋測試增加的或改變的代碼模塊。
- 相應地，他應該測試所有受改變影響的路徑。
- 并且，開發人員應該對那些與所修改的代碼關聯的地方做一些相對沒有那么嚴格的測試。例如，如果代碼改變的是參數的集合，那么應該測試那些參數被用到的地方。
單元測試的客觀證據
計劃所有這些測試都是好的，但是也需要一些客觀的方式來驗證測試被真正執行了。應該收集和保存什么證據來表明開發人員已經執行了那些測試？并且測試得到期待的結果？我們如何知道所有我們決定要做的這些測試已經做了并且做對了呢?
很明顯，我們加給開發人員的驗證檢查的負擔應該合理，并且要考慮測試被無意忽略的風險。我們不想強加不必要的作業；我們只是想確保當開發人員說一個模塊已經準備好提交了，我們都知道這意味著什么。
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/
