【譯】單元測試最佳實踐

編寫單元測試有以下好處：

• 利於迴歸測試
• 提供文檔
• 改進代碼設計

可是，難以閱讀和維護的測試代碼則會拔苗助長。本文會提供一些編寫單元測試的最佳實踐以使得你的測試代碼易於維護和理解。

爲何要寫單元測試？

1. 花更少的時間進行功能測試

功能測試成本相對較高，由於常常須要打開應用並執行一系列操做以驗證結果是否符合預期。測試步驟所涉及領域未必是測試人員所熟知，致使須要其餘人協助進行測試。對於細微變化，測試可能需幾秒鐘，亦或幾分鐘來測試較大的變動。最後，對於系統中的每處修改都須要進行重複測試。

反觀單元測試，僅需毫秒級別且無需對系統自身瞭解過多。單元測試經過與否取決於測試運行器（test runner），而不是某我的。

2. 避免迴歸測試

迴歸缺陷是在對應用程序進行更改時引入的缺陷。測試人員不只要測試他們的新特性，還要測試之前存在的特性，以驗證以前實現的特性是否仍然像預期的那樣運行。

經過單元測試，能夠在每次構建以後，即使是隻修改了一行代碼，從新運行整個測試流程，以確保新代碼不會破壞已有功能。

3. 可執行的文檔

有時對於特定的參數，方法的預期輸出難以肯定。你或許會問，若是向方法中傳入空字符串或者null會發生什麼？

當編寫具備良好命名的測試用例時，每一個用例能夠清晰的說明對於給定的輸入會有怎樣的輸出。此外，測試用例還應能夠驗證方法是否可以正常工做。

4. 低耦合代碼

編寫單元測試能夠下降代碼耦合度，由於高耦合的代碼將會使得單元測試變得困難重重。

良好的單元測試應具有如下特徵

• 快速
  對於大型成熟項目可能會有數千個測試用例。每一個測試用例應儘量快的運行，最好在毫秒級別。
• 隔離
  單元測試是獨立的，能夠單獨運行而不依賴外部元素，如文件系統或數據庫。
• 可重複
  在不改變輸入的狀況下，單元測試的輸出結果應保持不變。
• 自檢查
  單元測試應自動檢測測試是否經過而無需人工干預。
• 耗時少 若是測試代碼所花費的時間遠超編寫代碼的時間，應當考慮重構代碼以便於更好測試。即，確保編寫測試所花費的