單元測試框架的開發流程

簡介 

單元測試能夠更快地發現代碼中的錯誤，所以各個編程語言都擁有了專門的單元測試框架。本文按照通常的開發流程來討論單元測試框架，即需求分析、設計實現，應用模型等等，但願能夠提取單元測試的共性，爲理解不一樣的測試框架提供支持。

需求分析 

 從單元測試的機制能夠發現一部分隱藏需求，總結以下：

• 獨立測試：針對一個軟件單元。 
• 用例組織：能夠選擇執行測試。 
• 自動執行測試用例：能夠重複執行。 
• 自動驗證測試結果：能夠幫助排錯過程。 

知足以上幾點，單元測試甚至能夠做爲一個能夠執行的規格說明和文檔。

設計實現

現有的單元測試通常由一個軟件框架支持，提供對需求的基本支持，以gtest爲例：

• 獨立測試：與待測單元單獨造成一個執行文件，並在適當的時候完成測試場景的設置與拆除。
• 用例組織：提供三級結構：環境、用例、用例對象
• 自動執行：能夠經過環境變量、命令行等等輸入測試用例的名字，支持正則表達式。
• 自動驗證：提供一些原語，例如EXPECT_EQ等。這些原語會提供一些信息，例如是否成功，在那一行上失敗，額外的信息提示等等。

測試框架的序列圖如上，其中Fixture是須要用戶定製的測試場景，最簡單的狀況就是場景中只有待測系統SUT，並且不須要設置，例如測試一個函數時的狀況。

應用

軟件框架只有定製之後，才能發揮做用。對於不一樣應用場景的定製，仍然遵循通常的軟件原則，例如模塊化，DRY（不要重複本身），開閉原則（對修改封閉，對擴展開放）等等。須要強調的是：

• 簡單測試：測試自己的代碼必須簡單，例如無分支語句，不然還要寫測試代碼的測試。
• 幫助排錯：測試失敗以後，要提供幫助排錯的信息；測試目的儘量簡單，使得失敗緣由一目瞭然。
• 測試場景：
  • 　　設置獨立的測試場景，可能會有性能問題，須要考慮一些針對性的方案。
  • 　　爲了解決待測系統的依賴性，須要設置測試替身，同時也能完成一些對象交互的驗證工做。
• 可測試性設計：方便設置測試替身，儘量減小不可測代碼。

結語

開發單元測試框架仍然須要遵照通常的開發規範，所以從框架規範中整理出框架背後的需求、設計和實現的一些內容，對於理解和執行單元測試，能夠提供額外的幫助。

參照 

[1] Gerard Meszaros，XUnit test patterns : refactoring test code，Pearson Education, Inc，  2007 

[2] Gtest, https://code.google.com/p/googletest/wiki/V1_7_Documentation 

[3] Gtest, http://www.cnblogs.com/coderzh/archive/2009/04/06/1426755.html