摘要
編寫單元測試代碼是一件很困難的工作。大多數情況下，我們需要測試那些以前沒有編寫過的使用復雜的協作軟件（如數據庫，應用程序服務器或軟件模塊）的代碼。我們可能還需要處理一些難以在測試環境下生成的條件。建立這些依賴關系可能需要相當長的時間，這抵消了其自動測試方面的優勢。本文將著重介紹Mock Objects――來自XP社區的一項測試技術（XP社區提供了一種獨立的代碼測試，這種測試是通過模擬外部依賴來實現的）。和使用任何其它工具一樣，我們要謹慎，防止濫用。
Mock Objects概述
近些年來，開發人員又重新發現了自己編寫測試代碼的好處。他們認同，發現并修改軟件中的錯誤所付出的代價是昂貴的。結果，Unit Testing作為查找代碼錯誤和幫助確定系統需求的方法，成為了軟件開發流程中不可或缺的一部分。單元測試的主要目標是獨立地對每一個工作單元（通常是一個類）進行測試。獨立代碼測試是一件困難的工作，尤其是難以在測試中快速建立依賴關系的情況下。編寫和維護單元測試代碼的難度越大，開發人員越容易失去信心，并停止編寫測試代碼。
Tim Mackinnon、Steve Freeman和Philip Craig在他們的文章“Endo-Testing: Unit Testing with Mock Objects”中對Mock對象的基本概念進行了介紹，這篇文章發表在XP2000上。Mock對象（或Mock）模擬代價昂貴且難以使用的協作軟件，并提供了一種方法用于：
在測試環境中建立復雜的依賴關系（例如，模擬數據庫連接，代替真正的數據庫連接）
驗證測試行為是否符合期望結果（例如，驗證JDBC連接在使用結束后關閉――也是在特定時刻調用 java.sql.Connection中的 close方法）
模擬難以生成的環境條件（例如，模擬JDBC驅動程序拋出的 SQLException 類）。
雖然很有用，但Mock并不是的，濫用Mock所帶來的壞處將會大于它為項目帶來的好處。
Mock的缺點
Mock程序員需要注意以下幾個問題。
Mock可能會隱藏集成問題
尤其是，如果我們只使用Mock進行代碼測試，而不編寫集成測試，則這種情況很可能發生。
請考慮圖1中的例子。
圖1.將新員工信息存儲于數據庫中
EmployeeBO類提供了與Employees有關的業務服務，并使用EmployeeDAO通過JDBC將數據持久存儲在關系數據庫中。測試EmployeeBO意味著建立一個數據庫，并用它來存儲數據。
