1  構(gòu)筑測試體系

如果你想進(jìn)行重構(gòu)，首要前提就是要擁有一個可靠的測試環(huán)境。

“編寫優(yōu)良的測試程序，可以極大的提高我的編程速度，即使不進(jìn)行重構(gòu)也是如此?！?

1.1  自我測試代碼（Self-testing Code ）的價值

“Class 應(yīng)該包含他們自己的測試代碼?！?

“每個Class 都有一個測試函數(shù)，并用它測試自己這個 Class ?！?

確保所有的測試都完全自動化，讓它們檢查自己的測試結(jié)果。

只要寫好一點功能，就立即添加測試。

一整組（a suite of ）測試就是一個強大的“臭蟲”偵測器，能夠大大縮減查找“臭蟲”所需要的時間。

“實際上，編寫測試代碼的最有用時機(jī)是在開始編程之前。當(dāng)你需要添加特性的時候，先寫相應(yīng)的測試代碼。聽起來離經(jīng)叛道，其實不然。填寫測試代碼其實就是問自己：添加這個功能需要做什么。編寫測試代碼還能使你把注意力集中于接口而非實現(xiàn)上頭（永遠(yuǎn)是件好事）。預(yù)先寫好的測試代碼也為你的工作按上一個明確的結(jié)束標(biāo)志：一旦測試代碼運行正常，工作就可以結(jié)束了?！?

構(gòu)建自我測試的代碼。

1.2  JUnit測試框架（ Testing Framew ）

頻繁的運行測試，每次編譯請把測試也考慮進(jìn)去，每天至少執(zhí)行每個測試一次。

單元測試和功能測試

“每當(dāng)你接獲臭蟲提報，請先撰寫一個單元測試來揭發(fā)這只臭蟲?！薄绾谓野l(fā)？這里需要根據(jù)報告準(zhǔn)確定位。單元測試會對此有幫助嗎？

1.3  添加更多的測試

“觀察Class 該做的所有事情，然后針對任何一項功能的任何一種可能失敗的情況，進(jìn)行測試?！?

“測試應(yīng)該是一種風(fēng)險驅(qū)動（risk driven ）行為，測試的目的是希望找出現(xiàn)在或未來的可能出現(xiàn)的錯誤。”

“測試的訣竅是：測試你最擔(dān)心的部分。”

這點和我目前的想法不大相同。我目前的想法是，測試要對程序做100% 的保證，所以，要測試程序可能行為的每一種情況，保證其正確性。按照我的想法，值域的設(shè)置和訪問函數(shù)也是要測試的。作者的意思是，測試代碼要用最低的成本，獲取最大的收益。這一點，要我在實際的環(huán)境中進(jìn)行抉擇。

“編寫不是十分完美的測試并實際運行，好過對完美測試的無盡等待?！薄页謶岩蓱B(tài)度。

運用測試用例前后執(zhí)行的函數(shù)：tearDown 和 setUp ，保證測試用例之間相互隔離，而非相互影響。

做一個懶惰的程序員——。

考慮可能出錯的邊界條件，把測試火力集中在那兒。

“測試（優(yōu)先）可以調(diào)高編程速度”，這一點我要在實踐中驗證一下，如果真是這樣，那我就要嘗試在我們部門推行這種方法。

“當(dāng)測試達(dá)到一定的程度后，測試效益會呈現(xiàn)遞減態(tài)勢。”所以，你不要期望通過測試找出所有的bug ，而是要通過測試，找出絕大多數(shù)的 bug 。

這個地方其實也符合“二八定律”：即20% 的測試可以找出 80% 的 bug ，其余的 80% 的測試可以找出剩下的 20% 的 bug 。我們要做的，就是寫這 20% 的測試，而非 100% 的測試。