第4章 測試哪些內容：Right-BICEP

4.1 結果是否正確 Right-BICEP

如果代碼能夠運行正確，我要怎么才知道它是正確的呢

  如果你不能很好地回答這個問題，那么編寫代碼——或者測試——完全就是在浪費時間。

  在代碼的整個生命期中，“正確”的定義可能會不斷在變；但是無論如何，你至少需要確認代碼所做的和你的期望是一致的。

·使用數據文件

  對于許多有大量測試數據的測試，你可能會考慮用一個獨立的數據文件來存儲這些測試數據，然后讓單元測試讀取該文件。

  多注意一下測試數據。經驗告訴我們，測試數據比代碼更有可能是錯的，特別是人工計算的，或者來自原有系統計算結果的測試數據。因此，當測試數據顯示有錯誤發生的時間，你應該在懷疑代碼前先對測試數據檢查兩三遍。

  一個原則是：對于驗證被測方法是正確的這件事情，如果某些做法能夠使它變得更加容易，那么就采納它吧。

4.2 邊界條件 Right-BICEP

找邊界條件是做單元測試中最有價值的工作之一，因為bug一般就出現在邊界上。一些需要你考慮得條件有。

·完全偽造或者不一致的輸入數據，例如一個名為“!*W:X\&Gi/w~>g/h#WQ@”的文件。

·格式錯誤的數據，例如沒有頂層域名的電子郵件地址就像fred@foobar這樣的。

·控制或者不完整的值（如0, 0.0, “”和null）。

·一些與意料中的合理值相去甚遠的數值。例如一個人的歲數為10000歲。

·如果要求的是一個不允許出現重復數值的list，但是傳入的是一個存在重復數值的list。

·如果要求的是一個有序list，但是傳入的是一個無序的list；或者反之。例如，給一個要求排好序的算法傳入一個未排序的list——甚至一個反序的list。

·事情到達的次序是錯誤的，或者碰巧和期望的次序不一致。例如，在未登錄系統之前，就嘗試打印文檔。

一個向導可能的邊界條件CORRECT。對于其中的每一條，都應該想想它是否與存在于被測方法中的某個條件非常類似，而當這些條件被違反的時，出現的又是什么情況。

·Conformance（一致性）——值是否和預期的一致。

·Ordering（順序性）——值是否如應該的那樣，是有序或者無序的。

·Range（區間性）——值是否位于合理的最小值和最大值之內。

·Reference（依賴性）——代碼是否引用了一些不再代碼本身控制范圍之內的外部資源。

·Existence（存在性）——值是否存在（例如，是否是非null，非0，再一個集合中等等）

·Cardinatity（基數性）——是否恰好有足夠的值？

·Time（相對或者絕對的時間性）——所有事情的發生是否是有序的？是否是在正確的時刻？是否恰好及時？

4.3 檢查反向關聯 Right-BICEP

  對于一些方法，我們可以使用反向的邏輯關系來驗證它們。

要注意的是：當你同時編寫了原方法和它的反向測試時，一些bug可能會被在兩個函數中都出現的錯誤所掩蓋。在可能的情況下，應該使用不同的原理來編寫反向測試。

4.4 使用其他手段來實現交叉檢查 Right-BICEP

通常而言，計算一個量會有一種以上的算法。我們可能會基于運行效率或者其他的特性，來選擇算法。那是我們要在產品中使用的；但是在測試用的系統中，可以使用剩下算法中的一個來交叉測試結果。當確實存在一種經過驗證并能完成任務的算法，只是由于速度太慢或者太不靈活而沒有在產品代碼中使用，這種交叉檢查的技術將非常有效。

另一種辦法就是：使用類本身不同組成部分的數據，并且確信它們能和“合起來”。

4.5 強制產生錯誤條件 Right-BICEP

在真實世界中，錯誤總是會發生：磁盤會慢，網絡連線會斷開，電子郵件會多的像掉進了黑洞，而程序會崩潰。你應當能夠通過強制引發錯誤，來測試你的代碼是如何處理所有這些真實世界中的問題的。

4.6 性能特性 Right-BICEP

一個檢查起來會很有益處的部分是性能特性，而不是性能本身。

你也許需要一些測試輔助工具。它們嫩構提供對單個測試進行計時，模擬告負在情況之類的功能，比如免費的JUnitPerf。