構筑測試體系
如果你想進行重構，首要前提就是要擁有一個可靠的測試環境。
“編寫優良的測試程序，可以極大的提高我的編程速度，即使不進行重構也是如此。”
1、自我測試代碼（Self-testing Code ）的價值
“Class 應該包含他們自己的測試代碼。”
“每個Class 都有一個測試函數，并用它測試自己這個 Class 。”
確保所有的測試都完全自動化，讓它們檢查自己的測試結果。
只要寫好一點功能，就立即添加測試。
一整組（a suite of ）測試就是一個強大的“臭蟲”偵測器，能夠大大縮減查找“臭蟲”所需要的時間。
“實際上，編寫測試代碼的最有用時機是在開始編程之前。當你需要添加特性的時候，先寫相應的測試代碼。聽起來離經叛道，其實不然。填寫測試代碼其實就是問自己：添加這個功能需要做什么。編寫測試代碼還能使你把注意力集中于接口而非實現上頭（永遠是件好事）。預先寫好的測試代碼也為你的工作按上一個明確的結束標志：一旦測試代碼運行正常，工作就可以結束了。”
構建自我測試的代碼。
2、JUnit測試框架（ Testing Framew ）
頻繁的運行測試，每次編譯請把測試也考慮進去，每天至少執行每個測試一次。
單元測試和功能測試
“每當你接獲臭蟲提報，請先撰寫一個單元測試來揭發這只臭蟲。”——如何揭發？這里需要根據報告準確定位。單元測試會對此有幫助嗎？
3、添加更多的測試
“觀察Class 該做的所有事情，然后針對任何一項功能的任何一種可能失敗的情況，進行測試。”
“測試應該是一種風險驅動（risk driven ）行為，測試的目的是希望找出現在或未來的可能出現的錯誤。”
“測試的訣竅是：測試你最擔心的部分。”
這點和我目前的想法不大相同。我目前的想法是，測試要對程序做100% 的保證，所以，要測試程序可能行為的每一種情況，保證其正確性。按照我的想法，值域的設置和訪問函數也是要測試的。作者的意思是，測試代碼要用最低的成本，獲取最大的收益。這一點，要我在實際的環境中進行抉擇。
“編寫不是十分完美的測試并實際運行，好過對完美測試的無盡等待。”——我持懷疑態度。
運用測試用例前后執行的函數：tearDown 和 setUp，保證測試用例之間相互隔離，而非相互影響。
做一個懶惰的程序員。
考慮可能出錯的邊界條件，把測試火力集中在那兒。
“測試（優先）可以調高編程速度”，這一點我要在實踐中驗證一下，如果真是這樣，那我就要嘗試在我們部門推行這種方法。
“當測試達到一定的程度后，測試效益會呈現遞減態勢。”所以，你不要期望通過測試找出所有的bug ，而是要通過測試，找出絕大多數的 bug 。
這個地方其實也符合“二八定律”：即20% 的測試可以找出 80% 的 bug，其余的 80% 的測試可以找出剩下的 20% 的 bug 。我們要做的，就是寫這 20% 的測試，而非 100% 的測試。
