### 自我測試代碼的價值 如果認真觀察程序員把最多時間耗在哪里，你就會發現，編寫代碼其實只占非常小的一部分。有些時間用來決定下一步干什么，另一些時間花在設計上面，最多的時間則是用來調試（debug)。我敢肯定每一位讀者都還記得自己花在調試上面的無數個小時，無數次通宵達旦。每個程序員都能講出「花一整天（甚至更多）時間只找出一只小小臭蟲」的故事。修復錯誤通常是比較快的，但找出錯誤卻是噩夢一場。當你修好一個錯誤，總是會有另一個錯誤出現，而且肯定要很久以后才會注意到它。 彼時你又要花上大把時間去尋找它。 我走上「自我測試代碼」這條路，肇因于1992年OOPSLA大會上的一次演講。會場上有人（我記得好像是Dave Thomas）說：『class應該包含它們自己的測試代碼。』這激發了我的靈感，讓我想到一種組織測試的好方法。我這樣解釋它：每個class都應該有一個測試函數，并以它來測試自己這個class。 那時候我還著迷于增量式開發（incremental development），所以我嘗試在結束每次增量時，為每個class添加測試。當時我開發的項目很小，所以我們大約每周增量 一次。執行測試變得相當直率，但盡管如此，做這些測試還是很煩人，因為每個測試都把結果輸出到控制臺（console），而我必須逐一檢查它們。我是個很懶的人，我情愿當下努力工作以免除日后的工作。我意識到我其實完全不必自己盯著屏幕檢 驗測試所得信息是否正確，我大可讓計算機來幫我做這件事。我需要做的就是把我所期望的輸出放進測試代碼中，然后做一個比較就行了。于是我可以舒服地執行每 個的測試函數，如果一切都沒問題，屏幕上就只出現一個“OK“。現在，這些classes都變成「自我測試」了。 TIP：確保所有測試都完全自動化，讓它們檢查自己的測試結果。 此后再進行測試就簡單多了，和編譯一樣簡單。于是我開始在每次編譯之后都進行測試。很快我發現自己的生產性能大大提高。我意識到那是因為我沒有花太多時間 去調試。如果我不小心引入一個可被原測試捕捉到的錯誤，那么只要我執行測試，它就會向我報告這個錯誤。由于測試本來是可以正常運行的，所以我知道這個錯誤必定是在前一次執行測試后引入。由于我頻繁地進行測試，每次測試都在不久之前，因此我知道錯誤的源頭就是我剛剛寫下的代碼。而由于我對那段代碼記憶猶新，份量也很小，所以輕松就能找到錯誤。從前需要一小時甚至更多時間才能找到的錯誤, 現在最多只需兩分鐘就找到了。之所以能夠擁有如此強大的偵錯能力，不僅僅因為我構筑了self-testing classes（自我測試類），也因為我頻繁地運行它們。 注意到這一點后，我對測試的積極性更高了。我不再等待每次增量結束，只要寫好 一點功能，我就立即添加測試。每天我都會添加一些新功能，同時也添加相應的測試。那些日子里，我很少花一分鐘以上的時間在調試上面。 TIP：一整組（a suite of）測試就是一個強大的「臭蟲」偵測器，能夠大大縮減查找「臭蟲」所耑要的時間。 當然，說服別人也這么做，并不容易。編寫測試程序，意味要寫很多額外代碼。除非你確切體驗到這種方法對編程速度的提升，否則自我測試就顯不出它的意義。很多人根本沒學過如何編寫測試程序，甚至根本沒考慮過測試，這對于編寫自我測試代碼也很不利。如果需要手動運行測試，那更是令人煩悶欲嘔；但如果可以自動運行，編寫測試代碼就真的很有趣。 實際上，撰寫測試代碼的最有用時機是在開始編程之前。當你需要添加特性的時候，先寫相應測試代碼。聽起來離經叛道，其實不然。編寫測試代碼其實就是在問自己：添加這個功能需要做些什么。編寫測試代碼還能使你把注意力集中于接口而非實現上頭（這永遠是件好事）。預先寫好的測試代碼也為你的工作安上一個明確的結束標志：一旦測試代碼正常運行，工作就可以結束了。 「頻繁進行測試」是極限編程（ extreme programming XP）[Beck, XP]的重要一 環。「極限編程」一詞容易讓人聯想起那些編碼飛快、自由而散漫的黑客（hackers)， 實際上極限編程者都是十分專注的測試者。他們希望盡可能快速開發軟件，而他們也知道「測試」可協助他們盡可能快速地前進。 爭論至此可休矣。盡管我相信每個人都可以從編寫自我測試代碼中受益，但這并不是本書重點。本書談的是重構，而重構需要測試。如果你想重構，你就必須編寫測 試代碼。本章將教你「以Java編寫測試代碼」的起步知識。這不是一本專講測試的 書，所以我不想講得太仔細。但我發現，少量測試就足以帶來驚人的利益。 和本書其他內容一樣，我以實例來介紹測試手法。開發軟件的時候，我一邊撰寫代 碼，一邊撰寫測試代碼。但是當我和他人并肩重構時，往往得面對許多無自我測試的代碼。所以重構之前我們首先必須把這些代碼改造為「自我測試」。 Java之中的測試慣用手法是“ testing main”，意思是每個class都應該有一個用于測試的main()。這是一個合理的習慣（盡管并不那么值得稱許），但可能不好操控。這種作法的問題是很難輕松運行多個測試。另一種作法是：建立一個獨立用 于測試，并在一個框架（framework）中運行它，使測試工作更輕松。