單元測試
爲什麼使用單元測試
試想一個情境，當有一個同事離職了，老闆交辦要開始維護他所留下來的程序，時間上不太允許重寫程序，老闆也不會答應。那要怎麼開始的呢？先看文件？然後再閱讀代碼，一邊碎念，一邊感嘆自己的悲情？假以時日後，才漸漸懂得如何運用前同事的程序？在這過程中，需求還是不斷進來，必須對原來已經穩定的程序加以修修改改，一不小心又藏了一隻bug。然後bug爆發，老闆就會質疑原本好好的程序怎麼會出包，最後開會被釘到牆上。很熟悉吧，也很無奈，難道這是程序員的宿命？
遇到這種情況該怎麼辦辦呢？
所以一般的流程是先讀代碼，瞭解代碼後，纔去運用。其間也沒有其他工具輔助，頂多畫畫流程圖。然後又換人接手維護，再一次進行前述的苦情循環。現有的開發環境和工具對這情形是沒有多大幫助的。但是一直等我遇到了單元測試，這情形就改觀了許多。
但是，當我們遇到單元測試後？
當我拿到像一鍋粥的代碼，我不會馬上跳進去和它們攪和一起。我會先快速掃一下，依據經驗找出程序壞味道（bad smell），針對這壞味道所在的目標程序，先進行單元測試撰寫。我會針對我對目標程序界面的認知，撰寫我自認爲正確邏輯的測試。然後測試它，如果測試pass，就是我的認知符合我對目標程序的期待，並且把這樣的認知，透過單元測試寫了下來，確認了這樣的“規格”；如果測試fail，就是我的認知和程序行爲不一致，要不是程序有問題，就是我的認知是錯的。此時我纔會跳進目標代碼，作細節探究。假設是我的認知錯誤，則修正測試程序；反之，就是目標程序的問題，就小心的修改目標程序，直到測試pass。
這樣的過程，不僅只有探索，而且記錄了結果。這還可以作爲日後的迴歸測試的依據。
這樣程序設計的思維方式從原本的讀碼->瞭解->使用，轉變成讀碼->使用->瞭解，僅是後兩步驟順序互換，就會帶來非常不一樣的效果。寫程序時的思維，會由原本的先了解程序細節切入如何使用，轉變成觀察使用的程序界面，探索如何使用。這有一點退一步觀賞的意味，不管是正在欣賞的是藝術作品，還是密密麻麻的代碼，道理是相似的。這樣就不容易當局者迷，墮入代碼的五里霧中，分辨不清方向。它也促使你重新思考這樣的設計是否合理，繼而考慮是否要重新設計。
JUnit
JUnit ——是一個開源的
Java 測試框架，主要用於編寫白盒測試，迴歸測試。無論白盒測試還是迴歸測試，都是運行可重複的測試。所謂”迴歸測試“——就是，軟件或環境的修復或更正後的“再測試”，自動測試工具對這類測試尤其有用；而所謂”單元測試“——就是，最小粒度的測試，以測試某個功能或代碼塊。一般由程序員來做，因爲它需要知道內部程序設計和編碼的細節。對於持續發展的產品，單元測試在後期的維護，迴歸有重要等方面有重要作用。
org.junit.Assert
Assert 包含了一組靜態的測試方法，用於期望值和實際值比對是否正確，即測試失敗，Assert 類就會拋出一個 AssertionFailedError 異常，JUnit 將這種錯誤歸入 Failes 並加以記錄，同時標誌爲未通過測試。如果該類方法中指定一個 String 類型的傳參則該參數將被做爲 AssertionFailedError 異常的標識信息，告訴測試人員改異常的詳細信息。
然後運行這個測試用例，右鍵點擊需要測試的類並且選擇 Run → Run As → JUnit Test。