單元測試準則（一）

　　1. 保持單元測試小巧， 快速理論上， 任何代碼 Check-in 以前都應該把全部測試套件完整的跑一遍. 因此保持測試代碼輕快能減小開發迭代週期.
 　　  2. 單元測試應該是全自動/非交互式的測試套件一般是按期執行的， 執行過程也必須是徹底自動化纔有意義. 輸出結果須要人工檢查的測試不是一個好的單元測試.
 　　  3. 讓單元測試很容易跑起來對開發環境進行配置， 最好是敲一條命令或是點擊一個按鈕就能把單個測試用例和測試套件跑起來.
 　　  4. 對測試進行評估對執行的測試進行覆蓋率分析， 以便獲得精確的代碼執行覆蓋率， 調查哪些代碼未被執行.
 　　  5. 當即修正失敗的測試每一個開發人員都應該保證新 Check-in 的測試用例可以跑成功， 而且當有代碼 Check-in 現有測試用例也都能跑經過.
 　　  6. 把測試維持在單元級別單元測試即類 (Class) 的測試. 一個 "測試類" 應該只對應於一個 "被測類"， 而且對 "被測類" 行爲的測試環境應該是隔離的. 必須謹慎的避免使用單元測試框架來測試整個程序的工做流， 這樣的測試即低效又難維護. 工做流測試 (譯註: 指跨模塊/類的數據流測試) 有它本身的地盤， 但它毫不是單元測試， 必須單獨設置和執行.
 　　  7. 由簡入繁再簡單的測試也遠遠賽過徹底沒有測試. 一個簡單的 "測試類" 會促使創建 "被測類" 基本的測試骨架， 能夠對構建環境， 單元測試環境， 執行環境以及覆蓋率分析工具等有效性進行檢查， 同時也確保 "被測類" 可以整合並被調用.下面即是單元測試版的 Hello， world! :void testDefaultConstruction(){Foo foo = new Foo();assertNotNull(foo);}
 　　  8. 保持測試的獨立性爲了保證測試穩定可靠且便於維護， 測試用例之間決不能有相互依賴， 也不能依賴執行的前後次序.
 　　  9. Keep tests close to the class being tested[譯註: 我未翻譯該規則， 我的認爲本條規則值得商榷， 大部分 C++ 和 Python 庫均把測試代碼從功能代碼目錄中獨立出來， 一般是建立一個和 src 目錄同級的 tests 目錄， 被測模塊/類名以前也經常 不加 Test 前綴. 這麼作保證功能代碼和測試代碼隔離， 目錄結構清晰， 而且發佈源碼的時候更容易排除測試用例.]If the class to test is Foo the test class should be called FooTest (not TestFoo) and kept in the same package (directory) as Foo. Keeping test classes in separate directory trees makes them harder to access and maintain.Make sure the build environment is configured so that the test classes doesn't make its way into production libraries or executables.
 　　  10. 合理的命名測試用例確保每一個測試方法只測試 "被測類" 的一個明確特性， 而且相應的給測試方法命名. 典型的命名俗定是 test[what]， 好比 testSaveAs()， testAddListener()， testDeleteProperty() 等.
 　　  11. 只測試公有接口單元測試能夠被定義爲 經過類的公有 API 對類進行進行測試. 一些測試工具容許測試一個類的私有成員， 但這種作法應該避免， 它讓測試變得繁瑣並且更難維護. 若是有私有成員確實須要進行直接測試， 能夠考慮把它重構到工具類的公有方法中. 但要注意這麼作是爲了改善設計， 而不是幫助測試.
 　　  12. 當作是黑盒從在第三方使用者的角度， 測試類是否知足規定的需求. 並設法讓它出問題 (譯註: 原文 tear it apart， 本意 "將它撕碎"， 個人理解是崩潰， 出問題， 不能正確工做).
 　　  13. 當作是白盒畢竟被測試類是程序員自寫自測的， 應該在最複雜的邏輯部分多花些精力測試.
 　　  14. 芝麻函數也要測試一般建議全部重要的函數都應該被測試到， 一些芝麻方法， 如簡單的 setter 和 getter 均可以忽略. 可是仍然有充分的理由支持測試芝麻函數:芝麻 很難定義. 對於不一樣的人有不一樣的理解.從黑盒測試的觀點看， 是沒法知道哪些代碼是普通的.即使是再芝麻的函數， 也可能包含錯誤， 一般是 "複製粘貼" 代碼的後果:private double weight_;private double x_， y_;public void setWeight(int weight){ weight = weight_; // error}public double getX(){ return x_;}public double getY(){ return x_; // error}所以建議測試全部方法. 畢竟芝麻函數也容易測試.
 　　 15. 先關注執行覆蓋率區別對待 執行覆蓋率 和 實際測試覆蓋率. 測試的最初目標應該是確保較高的執行覆蓋率. 這樣能保證代碼在 某些 參數輸入時能有效執行. 一旦執行覆蓋率就緒， 就應該開始改進測試覆蓋率了. 注意， 實際的測試覆蓋率很難衡量 (並且每每趨近於 0%).思考如下公有方法:void setLength(double length);調用 setLength(1.0) 你可能會獲得 100% 的執行覆蓋率. 要達到 100% 的實際測試覆蓋率， 有多少個 double 浮點數這個方法就必須被調用多少次， 而且要一一驗證行爲的正確性. 這無疑是不可能的任務.

本文轉自：http://www.spasvo.com/news/html/20131224170018.html