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 浮點數這個方法就必須被調用多少次, 并且要一一驗證行為的正確性。 這無疑是不可能的任務。

16 覆蓋邊界值

　　確保參數邊界值均被覆蓋。 對于數字, 測試負數, 0, 正數, 最小值, 最大值, NaN (非數字), 無窮大等。 對于字符串, 測試空字符串, 單字符, 非 ASCII 字符串, 多字節字符串等。 對于集合類型, 測試空, 1, 第一個, 最后一個等。 對于日期, 測試 1月1號, 2月29號, 12月31號等。 被測試的類本身也會暗示一些特定情況下的邊界值。 基本要點是盡可能徹底的測試這些邊界值, 因為它們都是主要 “疑犯”。

17 提供一個隨機值生成器

　　當邊界值都覆蓋了, 另一個能進一步改善測試覆蓋率的簡單方法就是生成隨機參數, 這樣每次執行測試都會有不同的輸入。

　　想要做到這點, 需要提供一個用來生成基本類型 (如: 浮點數, 整型, 字符串, 日期等) 隨機值的工具類。 生成器應該覆蓋各種類型的所有取值范圍。 

　　如果測試時間比較短, 可以考慮再裹上一層循環, 覆蓋盡可能多的輸入組合。 下面的例子是驗證兩次轉換 little endian 和 big endian 字節序后是否返回原值。 由于測試過程很快, 可以讓它跑上個一百萬次。

　　void testByteSwapper()

　　{ 

　　for (int i = 0; i < 1000000; i++) {

　　double v0 = Random。getDouble();

　　double v1 = ByteSwapper。swap(v0);

　　double v2 = ByteSwapper。swap(v1);

　　assertEquals(v0, v2);

　　}

　　}

18 每個特性只測一次

　　在測試模式下, 有時會情不自禁的濫用斷言。 這種做法會導致維護更困難, 需要極力避免。 僅對測試方法名指示的特性進行明確測試。

　　因為對于一般性代碼而言, 保證測試代碼盡可能少是一個重要目標。