解釋
1987年，IEEE就把單元測試納入美國國家標準。
針對應用程式設計的最小單位（程式模組）來進行正確性檢驗的測試工作。
理想的測試案例都依循不同案例；經常使用stubs、mock或fake等測試馬甲程式。
單元測試通常由軟體開發人員編寫，用於確保他們所寫的代碼符合軟體需求和遵循開發目標。
主要目標
將應用程式中的最小可測試片段（稱之為單元）與程式碼其餘部分隔離，已確定他的功能是否符合期望。
將各單元分開測試，可識別絕大部分的錯誤之處所在。對於物件導向而言，最小單元就是方法，包括基礎類別（超類）、抽象類、或者衍生類別（子類別）中的方法。
通用方法
需要撰寫驅動程式和 Stub 。
驅動程式模擬呼叫單元，而 Stub 模擬被呼叫的單元。
驅動程式和 Stub 需要花費相對應成本。驅動程式和 Stub 可重複使用，因此可經常重新測試，而不必撰寫大量額外的測試程式碼，而且重新測試的成本也比較好控制。
優點
然而單元測試仍然提供一些難以拒絕的優點。
- 它允許測試程序自動執行，可幫助我們更容易找出應用程式較複雜的程式片段中所含的錯誤。
- 因為注意力是集中於各單元，可幫助我們做更全面的測試，涵蓋的範圍通常可以增加。
重要觀念
＊ 目標程式
單元測試要測試的程式目標。
＊ 單元測試種類
TDD (Test-Driven Development)：目標程式不存在前撰寫的單元測試。將撰寫程式的流程從原先的寫碼>測試>重構轉變為測試>寫碼>重構，先訂定程式目標及規範，避免過度設計，寫出來的程式碼 100% 可以被測試，測試涵蓋率百分百。
BDD (Behavior-Driven Development)：目標程式已存在後，所撰寫的單元測試。 程式完成後，維護人員針對目標程式介面的初步認知，依循邏輯撰寫單元測試來進行測試，發生錯誤時，可分析是否是程式本身存在的問題，或是維護人員認知錯誤。
＊ JAVA單元測試工具、函式庫
＊ JUint 參考
＊ 整合單元測試
若您有兩個單元，並決定將它們合在一起，然後當作整合單元來進行初始測試比較划算，則在許多地方可能會發生錯誤：
- 錯誤導因於單元 1 的缺失嗎？
- 錯誤導因於單元 2 的缺失嗎？
- 錯誤導因於這兩個單元的缺失嗎？
- 錯誤導因於單元之間介面的缺失嗎？
- 錯誤導因於測試的缺失嗎？
找出整合式模組中的錯誤，比先隔離單元、逐一進行測試、整合之後再進行整體測試還要複雜。