Java, Only Java!

• 3.1 構(gòu)建單元測試
• 3.2 JUnit的各種斷言
• 3.3 JUnit框架

總覽

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

第2章 首個單元測試

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

第3章 使用JUnit編寫測試

3.1 構(gòu)建單元測試

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

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

  3.2 JUnit的各種斷言

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

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

3.3 JUnit框架

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

4. 測試什么？

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

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

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

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

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

6.使用Mock對象

Mock對象解決的問題：

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

Mock對象解決的步驟：

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

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

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

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

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

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

8. 在項(xiàng)目中進(jìn)行測試

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

9. 設(shè)計話題

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