Java, Only Java!

• 3.1 構建單元測試
• 3.2 JUnit的各種斷言
• 3.3 JUnit框架

總覽

這是本相對簡單的書，書中采用的JUnit的版本也是舊的，但是在新的JUnit4下稍做修改依然可以運行。重要的是通過這本書了解JUnit在Java的單元測試中是如何使用的。

第2章 首個單元測試

計劃你的測試：測試不是無中生有的，也不是意想天開的。是根據(jù)需要一點點添加的，幫助自己盡早地發(fā)現(xiàn)思考上的誤區(qū)。參看這章給出的例子，原來理所當然正確的，結果不一定是正確的。

第3章 使用JUnit編寫測試

3.1 構建單元測試

測試代碼必須要做的幾件事情：

• 準備測試的條件（創(chuàng)建對象、分配資源等等）
• 調用測試的方法
• 驗證測試方法的行為與期望是否相符
• 測試結束后清理現(xiàn)場（釋放資源等等）

  3.2 JUnit的各種斷言

  斷言：JUnit提供的輔助函數(shù)，幫助你確認被測試函數(shù)是否正確運行。

后面還介紹了（3.5 JUnit的自定義斷言）

3.3 JUnit框架

這章是基于JUnit3.x寫的，建議了解就可以了，因為JUnit4的變化較大，使用也更方便直觀，因此直接參考JUnit4的幫助。

4. 測試什么？

6個需要測試的地方（Right-BICEP）：

• Right：結果是否正確（Right）；
• B：邊界（Boundary）條件是否正確(CORRECT)；參考第5章
• I：能否檢查反向（Inverse）關系；
• C：進行交叉檢查（Cross-Check）的其他手段；
• E：強制錯誤（Error）條件發(fā)生；使用Mock對象實現(xiàn)，參考第6章
• P：滿足性能（Performance）的要求。

測試內容較多時，可以使用測試數(shù)據(jù)文件進行準備。但是使用文件后就沒有測試代碼看起來那么直觀了，因此除非測試內容非常復雜，否則沒有必要采用這樣的方式。并且如果測試文件出現(xiàn)錯誤（作者書中就出現(xiàn)了數(shù)據(jù)錯誤），還會導致測試不通過，增加了維護的成本。

5.CORRECT（正確的）邊界條件

• 一致性（Conformance）：值是否符合預期的格式；
• 有序性（Ordering）：一組值是否符合對排序的要求（有序性、無序性）；
• 區(qū)間性（Range）：值是否在合理取值范圍內（在最小值與最大值之間）；
• 引用（Reference）-耦合性：代碼是否引用了不受代碼本身直接控制的外部因素；
• 存在性（Existence）：值是否存在（例如：非NULL，非零，包含于某個集合等等）
• 基數(shù)性（Cardinality）：是否恰好有足夠的值；（也稱為集合的勢，即集合里面包含的元素個數(shù)）
• 時間性（Time）-絕對時間和相對時間：所有的事情是否按照順序發(fā)生？是否在正確的時間發(fā)生？是否及時發(fā)生？

6.使用Mock對象

Mock對象解決的問題：

• 真實對象具有不可確定的行為（如：股票行情）；
• 真實對象很難被創(chuàng)建；
• 真實對象的某些行為很難被觸發(fā)（如：網(wǎng)絡錯誤）；
• 真實對象令程序的運行速度很慢；
• 真實對象有用戶界面或者就是用戶界面；
• 真實對象需要被詢問它是如何被調用的（如：驗證某個回調函數(shù)是否被調用）；
• 真實對象實際上不存在（如：其他開發(fā)小組的接口、或者某個沒有的硬件產(chǎn)品）。

Mock對象解決的步驟：

• 使用一個接口來描述這個對象；
• 為產(chǎn)品代碼實現(xiàn)這個接口；
• 以測試為目的，在Mock對象中實現(xiàn)這個接口。

注：這里的Mock不是網(wǎng)上已經(jīng)形成框架的Mock工具，是Mock的實現(xiàn)原理。作者推薦的Mock工具是EasyMock。其他的Mock工具可以參考《[使用Mock進行單元測試]》(https://blog.csdn.net/u011393781/article/details/52669772)

7. 好的測試所具有的品質(A-TRIP)

• 自動化（Automatic）：自動化地調用測試和檢查結果；常用的持續(xù)集成工具
• 徹底的（Thorough）：測試了所有需求關注的情況；常用的代碼覆蓋工具
• 可重復（Repeatable）：每個測試應該獨立于其他所有的測試，還必須獨立于環(huán)境，從而可以重復地執(zhí)行，并且產(chǎn)生相同的結果。
• 獨立的（Independent）：確保一個函數(shù)只針對一樣測試，并且這個測試不依賴于其他測試。
• 專業(yè)的（Professional）：測試代碼應該與產(chǎn)品代碼的編碼風格和編寫質量相同

如何確保測試代碼是正確的呢？

• 對產(chǎn)品代碼中的Bug進行修改的時候也改進測試代碼；（因為這個Bug是測試代碼沒有發(fā)現(xiàn)的）
• 在產(chǎn)品代碼中引入Bug來驗證測試代碼的正確性。（確保可能會發(fā)生的錯誤被測試代碼捕捉到了）

8. 在項目中進行測試

• 把測試代碼與產(chǎn)品代碼放在一個目錄下；
• 與別人共享代碼的時候，需要確保你的代碼可以通過所有測試；
• 測試的時間點：
  • 編寫新的函數(shù)；
  • 修正Bug；
  • 每次成功編譯之后；
  • 每次對版本控制的提交；
  • 持續(xù)不斷地由專門的機器來運行完整的構建和測試。
• 測試別人的項目代碼：其實就是維護別人的項目絕對是個大問題，同時也是個必須面對的問題。需要理性的態(tài)度（不批評別人的代碼）、冷靜的手段（不隨便修改別人的代碼）、持久的耐心（先從測試代碼開始，慢慢重構項目代碼，使之重新回到健康狀態(tài)）、真正的智慧（知道什么樣的項目應該達到什么樣的目標，不執(zhí)著于重構成一個完美的狀態(tài)，也不簡單放棄隨之自生自滅。）
• 測試與評審：三個臭皮匠頂個諸葛亮，放下自我的執(zhí)著，接納各種不同的意見，才能做出令自己滿意的項目。

9. 設計話題

• 面向測試的設計：不方便測試的設計不是好的設計；說明設計過于僵化或者臃腫，需要簡化或者修改使之更利用未來的擴展和維護。
• 面向測試的重構：不方便測試的代碼不是好的代碼；說明業(yè)務混雜在一起，無法實現(xiàn)一個函數(shù)只針對一樣測試，需要修改設計使業(yè)務分離。
• 測試類的不變性：就是對類的斷言必須為真。
  • 有序性。例如：sorted list類的不變性就是無論發(fā)生什么，結果都應該是有序的。
  • 結構化。例如：訂單系統(tǒng)中每個條目必須屬于一個訂單，一個訂單擁有一個或多個條目。
  • 數(shù)學不變性。例如：銀行賬號的的借貸必須平衡。
  • 數(shù)據(jù)一致性。例如：商品總數(shù)=庫存數(shù)+銷售數(shù)。
• 測試驅動的設計。使你作為產(chǎn)品代碼的用戶在編碼，而不是產(chǎn)品開發(fā)者在編碼，開發(fā)結果更能反應用戶的需求。
• 測試無效的參數(shù)。當你作為產(chǎn)品代碼的用戶時，你才能真正確定哪些責任應該你來承擔，而哪些是不需要的。例如：無效的參數(shù)應該由哪個函數(shù)來承擔檢查責任呢？