解釋

1987年,IEEE就把單元測試納入美國國家標準。
針對應用程式設計的最小單位(程式模組)來進行正確性檢驗的測試工作。
理想的測試案例都依循不同案例;經常使用stubs、mock或fake等測試馬甲程式。
單元測試通常由軟體開發人員編寫,用於確保他們所寫的代碼符合軟體需求和遵循開發目標。

主要目標

將應用程式中的最小可測試片段(稱之為單元)與程式碼其餘部分隔離,已確定他的功能是否符合期望。
將各單元分開測試,可識別絕大部分的錯誤之處所在。對於物件導向而言,最小單元就是方法,包括基礎類別(超類)、抽象類、或者衍生類別(子類別)中的方法。

通用方法

需要撰寫驅動程式 Stub
驅動程式模擬呼叫單元,而 Stub 模擬被呼叫的單元。
驅動程式和 Stub 需要花費相對應成本。驅動程式和 Stub 可重複使用,因此可經常重新測試,而不必撰寫大量額外的測試程式碼,而且重新測試的成本也比較好控制。

優點

然而單元測試仍然提供一些難以拒絕的優點。

  • 它允許測試程序自動執行,可幫助我們更容易找出應用程式較複雜的程式片段中所含的錯誤。
  • 因為注意力是集中於各單元,可幫助我們做更全面的測試,涵蓋的範圍通常可以增加。

重要觀念

* 目標程式

單元測試要測試的程式目標。

* 單元測試種類
  • TDD (Test-Driven Development):目標程式不存在前撰寫的單元測試。將撰寫程式的流程從原先的寫碼>測試>重構轉變為測試>寫碼>重構,先訂定程式目標及規範,避免過度設計,寫出來的程式碼 100% 可以被測試,測試涵蓋率百分百。

  • BDD (Behavior-Driven Development):目標程式已存在後,所撰寫的單元測試。 程式完成後,維護人員針對目標程式介面的初步認知,依循邏輯撰寫單元測試來進行測試,發生錯誤時,可分析是否是程式本身存在的問題,或是維護人員認知錯誤。

* JAVA單元測試工具、函式庫
  1. JUnit 4
  2. Mockito
  3. EasyMock
  4. PowerMock
* JUint 參考
* 整合單元測試

若您有兩個單元,並決定將它們合在一起,然後當作整合單元來進行初始測試比較划算,則在許多地方可能會發生錯誤:

  • 錯誤導因於單元 1 的缺失嗎?
  • 錯誤導因於單元 2 的缺失嗎?
  • 錯誤導因於這兩個單元的缺失嗎?
  • 錯誤導因於單元之間介面的缺失嗎?
  • 錯誤導因於測試的缺失嗎?

找出整合式模組中的錯誤,比先隔離單元、逐一進行測試、整合之後再進行整體測試還要複雜。

參考來源
  1. 單元測試-Microsoft Developer Network
  2. 單元測試 - 維基百科,自由的百科全書
  3. 【單元測試】改變了我程式設計的思維方式 by pcbill | CodeData
  4. Java 程式的單元測試 @ Simon’s Software Sky :: 隨意窩 Xuite日誌