一、對系統改動的兩種方式
在書中，作者很有意思的描述了對系統改動的兩種改動方式：
實際上來說，幾乎大部分人都是按照第一種做法來做的。先確保理解代碼，然後找到改動點，編輯之後，再花大量的時間來確認改動是否生效，改動是否破壞了其他功能。這裏存在的問題，首先是，這種方式意味着修改都要非常小心，並且，當這個改動對系統侵入性較強的時候，還需要倍加小心，不然出錯的可能性會更大；即使如此，改動的安全性並不僅僅意味着小心，沒有正確的工具和技術，小心也起不了多大作用。
覆蓋並修改則是另外一種方式。覆蓋軟件的意思是用測試來覆蓋它，當對一組代碼有一組良好的測試時，我們就可以放心地對它進行修改，並快速檢驗出好壞。相比傳統的測試做法不同的是，傳統的測試總是在開發後進行，而測試員的工作安排有可能導致整個反饋週期長得難以接受，只要有1-2輪返工，工期就很可能被延期。
對於覆蓋軟件的測試，單元測試比系統層面的迴歸測試也要更好，一分鐘可以得到的反饋，相比等幾個小時，顯然是要更有效率的。對一段代碼，如果被一組單元測試徹底覆蓋了，那在接下來對這段代碼進行重構或修改的時候，我們可以在很短的時間內得到足夠多的反饋，大大增強了重構的安全性。
當然，和第一種方法相比，覆蓋軟件起碼在表面上也意味着更多的工作量。但是從日常開發工作中，我們很容易得到這樣的經驗：開發工作量大在大部分時候都不是我們項目延期和加班的原因，而程序中層出不窮難以調試的bug，纔是導致我們工作進展困難的罪魁禍首。
二、什麼是單元測試
單元測試一般是針對一個系統最爲原子的行爲單元的測試。比如過程式語言中的函數或者說面嚮對象語言中的類。
在單元測試中，測試隔離性是一個重要方面，覆蓋代碼更廣泛功能的測試也很重要，但是較大型的測試存在一些問題：
- 難以定位錯誤。測試離被測對象更遠，關聯的其他因素越多，當測試失敗時，就越難定位問題的所在。
- 執行時間太長。較大型的測試往往需要更多的時間來運行，這也意味着需要更多的時間來得到反饋。而因爲花費的時間多，開發人員就越不願意多次執行。
- 覆蓋面不足。因爲測試離測試對象太遠，往往很難確定某段代碼和測試用例之間的關係，即使通過工具找出來未被覆蓋的代碼塊，依然需要花費大量的腦筋去考慮如何增加用例去覆蓋改代碼塊。
好的單元測試應該具有以下品質：
- 運行快。
- 能夠幫我們定位問題所在。
有些測試很容易和單元測試混淆起來，比如以下測試就不是單元測試，即使我們通常也會在單元測試用具中編寫這些測試：
- 和數據庫有交互；
- 進行了網絡通訊；
- 調用了文件系統；
- 需要做特定準備（如編輯配置文件）才能運行；
二、高層測試及其作用
單元測試非常有用，但高層測試也有一定作用。高層測試是指覆蓋了某個場景和交互的測試，可以用來確定一組類的行爲。單元測試所能覆蓋的只是類本身，如果和其他類有依賴，我們還要儘可能解開。這樣帶來的一些問題就是，有時候我們沒辦法確定兩個類的交互形式就是我們所想要的，高層測試可以覆蓋到一組類和它們之間的交互。
三、測試覆蓋
對於遺留代碼的測試覆蓋，可以使用以下步驟，關於步驟具體的實施方法，是後續的內容：
- 確定修改點；
- 找出測試點；
- 解依賴；
- 編寫測試；
- 修改重構
