#### [單元測試](https://lingcoder.gitee.io/onjava8/#/book/16-Validating-Your-Code?id=%e5%8d%95%e5%85%83%e6%b5%8b%e8%af%95) 這個過程是將集成測試構建到你創建的所有代碼中，并在每次構建系統時運行這些測試。這樣，構建過程不僅能檢查語法的錯誤，同時也能檢查語義的錯誤。 “單元”是指測試一小部分代碼 。通常，每個類都有測試來檢查它所有方法的行為。“系統”測試則是不同的，它檢查的是整個程序是否滿足要求。 C 風格的語言，尤其是 C++，通常會認為性能比安全更重要。用 Java 編程比 C++（一般認為大概快兩倍）快的原因是 Java 的安全性保障：比如垃圾回收以及改良的類型檢測等特性。通過將單元測試集成到構建過程中，你擴大了這個安全保障，因而有了更快的開發效率。當發現設計或實現的缺陷時，可以更容易、更大膽地重構你的代碼。 我自己的測試經歷開始于我意識到要確保書中代碼的正確性，書中的所有程序必須能夠通過合適的構建系統自動提取、編譯。這本書所使用的構建系統是 Gradle。 你只要在安裝 JDK 后輸入**gradlew compileJava**，就能編譯本書的所有代碼。自動提取和自動編譯的效果對本書代碼的質量是如此的直接和引人注目，（在我看來）這會很快成為任何編程書籍的必備條件——你怎么能相信沒有編譯的代碼呢? 我還發現我可以使用搜索和替換在整本書進行大范圍的修改，如果引入了一個錯誤，代碼提取器和構建系統就會清除它。隨著程序越來越復雜，我在系統中發現了一個嚴重的漏洞。編譯程序毫無疑問是重要的第一步， 對于一本要出版的書而言，這看來是相當具有革命意義的發現（由于出版壓力， 你經常打開一本程序設計的書會發現書中代碼的錯誤）。但是，我收到了來自讀者反饋代碼中存在語義問題。當然，這些問題可以通過運行代碼發現。我在早期實現一個自動化執行測試系統時嘗試了一些不太有效的方式，但迫于出版壓力，我明白我的程序絕對有問題，并會以 bug 報告的方式讓我自食惡果。我也經常收到讀者的抱怨說，我沒有顯示足夠的代碼輸出。我需要驗證程序的輸出，并且在書中顯示驗證的輸出。我以前的意見是讀者應該一邊看書一邊運行代碼，許多讀者就是這么做的并且從中受益。然而，這種態度背后的原因是，我無法保證書中的輸出是正確的。從經驗來看，我知道隨著時間的推移，會發生一些事情，使得輸出不再正確（或者一開始就不正確）。為了解決這個問題，我利用 Python 創建了一個工具（你將在下載的示例中找到此工具）。本書中的大多數程序都產生控制臺輸出，該工具將該輸出與源代碼清單末尾的注釋中顯示的預期輸出進行比較，所以讀者可以看到預期的輸出，并且知道這個輸出已經被構建程序驗證過。