SQ3R閱讀法：
Survey：閱讀之前的瀏覽，查閱
1、書名：《Pragmatic unit testing：in java with Junit》，中文譯名《單元測試之道Java版：使用JUnit》，是作者編著的程序員修煉三部曲中的一部，分別是《Pragmatic Version Control》、《Pragmatic Unit Testing》和《Pragmatic Automation》。
2、作者：
關於作者：
Andy Hunt(Andrew Hunt)，著名軟件開發書籍方面作者，是敏捷軟件開發聯盟的17位奠基人之一，和搭檔David Thomas合著一系列經典書籍：
《The Pragmatic Programmer》
《Pragmatic Version Control Using CVS》
《Pragmatic Unit Testing in Java with JUnit》
《Pragmatic Unit Testing in C# with Nunit》
《Pragmatic Thinking and Learning: Refactor Your Wetware》
3、大體內容：
（1）沒有介紹junit如何實現, 也沒有大篇幅的介紹如何使用junit, 或者介紹junit的一些高級用法； 它講了做單元測試的一些原則, 單元測試測什麼, 什麼樣的單元測試纔是一個好測試。
Question：提出問題
Read：閱讀全書
第一章 序言（introduction）
1、單元測試的設計目的？
單元測試設計目的並不是爲了獲得一些更好的整體質量。它並不是一個針對最終用戶、項目經理和開發組長的工具；而是有程序員自己來完成，並且最終受益人也是程序員自己。我們爲了自身的利益去使用單元測試，從讓我們的工作變得更加輕鬆。
2、什麼是單元測試？
單元測試是開發者編寫的一小段代碼，用於檢驗被檢測代碼的一個很小、很精確功能是否正確。
3、執行單元測試的目的？
執行單元測試是爲了證明某段代碼的行爲確實和開發者所期望的一致。
第二章 首個單元測試（your first unit tests）
第三章 使用JUnit編寫測試（writing tests in junit）
1、JUnit中的各種斷言
（1）assertEuqals([String message],expected,actual)——“[]”中爲可選參數；
（2）assertEuqals([String message],expected,actual，tolerance)——tolerance代表容忍度，用於測試精度；
（3）assertNull（[String message],Object object）——測試是否爲空；
（4）assertNotNull（[String message],Object object）——測試是否爲空；
（5）assertSame([String message],expected,actual)——測試兩個參數是否引用同一對象，不是的話失敗；
（6）assertNotSame([String message],expected,actual)——測試兩個參數是否引用不同對象；
（7）assertTrue（[String message],boolean condition）——驗證給定的條件是否爲真；
（8）assertFalse（[String message],boolean condition）——驗證給定的條件是否爲假；
（9）fail（[String message]）——註定會失敗，用於標記不應到達的分支；
2、JUnit測試骨架
（1）一個import語句引入所有junit.framework.*下的類；
（2）一個extends語句讓你的類從TestCase繼承；
（3）一個調用super（String）的構造函數。
第四章 測試哪些內容：Right-BICEP（what to test：Right-BICEP）
1、6個值得首先進行測試的方面？
（1）Right——結果正確與否；
a、如果測試代碼運行正確，怎樣確實它確實是正確的，而不是看起來是正確的？
- 使用數據文件——數據尤其可能出錯，尤其是手工計算的數據；
（2）B(Boundary)——是否所有的邊界條件是正確的；
- 找出邊界條件是做單元測試中最有價值的工作之一，因爲bug一般都出現在邊界上；
- 簡單的記憶方法：單詞CORRECT;
- Conformance(一致性)——結果是否和預期一致；
- Ordering（順序性）——結果是否應該是這樣的；
- Range（區間性）——結果是否位於合理的最小值和最大值之間；
- Reference(依賴性)——代碼是否引用了一些不在代碼本身控制範圍之內的外部資源；
- Existence（存在性）——結果是否應該存在；
- Cardinality（基數性）——是否恰好有足夠的值；
- Time（相對或絕對的時間性）——所有事情的發生是否是有序的，是否是在正確的時刻？是否恰好及時？
（3）I(Inverse)——能查一下反向關聯嗎？
a、對於一些結果正確與否，我們可以使用反向的邏輯關係來驗證。（如檢查是否插入了某條數據，可以使用反向邏輯，通過查詢該條記錄來驗證）
（4）C(Cross-Check)——能用其他手段交叉檢查一下結果嗎；
a、通常來講，任何一個計算都會有一個以上的算法；可以使用不同的算法來實現交叉檢查結果；
（5）E(error Conditions)——是否可以強制錯誤條件發生；
a、現實世界中各種錯誤頻繁發生，要強制使代碼產生錯誤，已驗證對錯誤事件的處理；
b、一般常見的錯誤有如下幾種：
- 內存耗光
- 磁盤用滿
- 時鐘出現問題
- 網絡不可用或者出現問題
- 系統過載
- 調色板顏色數目有限
- 顯示分辨率過高或過低
（6）P(performance)——是否滿足性能要求。
a、確保系統性能問題。
第五章 CORRECT邊界條件（CORRECR boundary conditions）
第六章 使用mock對象（Use Mock Objects）
1、單元測試的目標是一次只驗證一個方法，但是如果一個方法依賴於其他難以操控的東西，如網絡、數據庫等，怎麼辦？——使用mock對象
2、mock對象——真實對象在測試期間的替身！
僞裝出真實世界的部分，然後集中精力寫好測試部分的代碼！
3、使用mock對象時的三個步驟
a、使用一個接口來描述這個對象
b、爲產品代碼實現這個對象
c、以測試爲目的，在mock對象中實現接口
第七章 好的測試具有的特性（properties of good tests）
1、好的測試應該具備的特性——A-TRIP
（1）自動化（Automatic）
- 自動化包括兩個方面：調用測試自動化、檢查結果自動化
（2）徹底的（Thorough）
- 徹底是指測試了所有的可能情況。
（3）可重複（Repeatable）
- 獨立於周圍的環境，能夠以任意的順序一次又一次地執行，並且得到相同的結果。
（4）獨立的（Independent）
- 對立於其他環境，獨立於其他測試。
（5）專業的（Professional）
- 測試代碼必須和產品代碼一樣
第八章 在項目中進行測試（testing on a project）
1、測試代碼的存放位置
（1）同一目錄
- 好處：測試代碼能夠訪問產品代碼中protected成員變量和函數；
- 壞處：測試代碼混淆在產品代碼中。
- 決策：小項目使用，大項目不能使用；
（2）子目錄
- 好處：測試代碼遠離產品代碼，但不至於很遠；
- 壞處：測試代碼和產品代碼在不同的包中，不能直接訪問protected成員變量和函數；除非測試代碼中使用了產品代碼的子類，且子類暴露了那些成員；
- 決策：不建議使用。
（3）並行樹
- 好處：測試代碼和產品代碼不在混淆在一起；
- 壞處：測試代碼大大遠離產品代碼；
- 決策：測試代碼都在一個包中，享受了先前的訪問權利。建議採用！
2、測試的禮貌
（1）時刻保證測試代碼能夠正確運行！——無論是獨自測試還是與別人一起測試！
3、測試的時機
（1）編寫很函數時；
（2）修正bug後；
（3）每次成功編譯後；
（4）每次更新代碼後；
（5）持續不斷地運行測試；
4、對於遺留代碼的測試
（1）對於新編寫的代碼，同時編寫測試代碼；
（2）對於已經存在的代碼，只對最容易出問題的代碼進行測試；
（3）對於此種情況，單元測試的最重要的作用是防止倒退：避免維護性的更正和修繕導致現存功能產生bug。
（4）迴歸測試至關重要！！
第九章 設計問題（Design Issues）
Recite：複述全文
Review：回顧全書