一般原則：
測試任何可能失敗的地方。
測試任何已經失敗的地方。
對于新加的代碼，在被證明正確之前，都可能是有問題的。
至少編寫和產品代碼一樣多的測試代碼。
針對每次編譯都做局部測試。
簽入代碼之前做全局測試。
需要回答的問題：
我如何知道代碼運行是否正確呢？
我要如何對它進行測試？
還有哪些方面可能會發生錯誤？
這個問題是否會在其他的地方出現呢？
測試哪些方面 ：使用junit 測試的6個方面，統稱為：Right-BICEP:
Right －－－ 結果是否正確？
B －－－ 是否所有的邊界條件都是正確？
I －－－ 能查一下反向關聯嗎？
C －－－ 能用其他手段交叉檢查一下結果嗎？
E －－－ 你是否可以強制錯誤條件發生？
P －－－ 是否滿足性能要求？
編寫測試用例原則，correct邊界條件：
conformance （一致性）－－ 值 是否和預期的一致。
Ordering（順序性）－－一組值是該有序或者無序的。
Range（區間性）－－值是否位于合理的最小值和最大值之內。
Reference（引用 、耦合性）－－代碼是否引用了一些不在代碼本身控制范圍之內的外部資源。
Existence（存在性）－－值是否存在（例如，是否是非null，非0，在一個集合中等等）。
Cardinatity（基數性）－－是否恰好有足夠的值？
Time（相對或者絕對的時間性）－－所有事情的發生是否是有序的？是否是在正確的時刻？是否恰好及時？
環境方面的因素：
內存耗光。
磁盤用滿。
時鐘出問題。
網絡不可用或者有問題。
系統過載。
調色板顏色數目有限。
顯示分辨率過高或者過低。
0－1－n 原則
Mock對象：
真實對象具有不可確定的行為（產生不可預測的結果，如股票行情）
真實對象很難被創建
真實對象的某些行為很難觸發（如網絡錯誤）。
真實對象令程序的運行速度很慢。
真實對象有（或者是）用戶界面。
測試需要詢問真實對象它是如何被調用的（例如，測試可能需要驗證某個回調函數是否被調用了）。
真實對象實際上并不存在（當需要和其他開發小組，或者新的硬件系統打交道的時候，這是一個普遍問題）。
借助于mock對象，我們就可以解決上面提到的所有問題。在使用mock對象進行測試的時候，總共有3個步驟，分別是：
1. 使用一個接口來描述這個對象。
2. 為產品代碼實現這個接口。
3. 以測試為目的，在mock對象中實現這個接口。
mock提供了所有系統功能的現成接口，所以在更多的時候，人們可能（也許吧）會使用它而不是直接調用諸如System.currentTimeMillis()這樣的東西，而是躲在接口背后擁有了控制一切行為的能力。
這就是mock對象的全部；偽裝出真實世界的某些部分，使你可以集中精力測試好自己編寫的代碼。讓我們接下來看看更加復雜的例子吧。
好的測試是一個A－TPIP：
1. 自動化 (Automatic). 調用測試自動化和檢查結果自動化。
2. 徹底的 (Thorough).
3. 可重復 (Repeatable).
4. 獨立的 (Independent).
5. 專業的 (Professional).
在你發現bug時，所需要做的就是以下四個步驟：
1.驗明bug；
2.編寫一個將失敗的測試來證明bug的存在。
3.修正代碼，讓測試通過。
4.驗證所有的測試仍然可以通過（也就是，你沒有在修補的時候損壞其他的測試）。
測試的頻率：
1.編寫新的函數 編譯并運行本地的單元測試。
2.修正bug 運行測試來讓bug現形；修并再次運行單元測試。
3.每次成功編譯之后 運行本地的單元測試。
4.每次對版本控制的簽入 運行所有的模塊或者系統的單元測試。
5. 持續不斷地 應當有一臺專門的機器來運行完整的構建和測試。每次都應該從頭開始，并且整天自動運行（要么是周期性的，要么是每當有版本控制的簽入行為的時候）
編碼和評審以這樣的順序進行：
1. 編寫test case 和/或測試代碼。
2. 評審test case 和/或測試代碼。
3. 經評審修改test case 和/或測試代碼。
4. 編寫能通過所有測試的產品代碼。
5. 評審產品代碼和測試代碼。
6. 在每次評審后，修改測試代碼和產品代碼。
在某些機器上測試失敗：
這究竟是為什么呢？這些機器之間有什么區別呢？
比較明顯的答案可能是下面這些資源的差異：操作系統版本號、運行庫、java運行引擎、數據庫驅動等。
統一使用junit 方法的setup 和 tearDown方法。