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意味著建立一個數據庫，并用它來存儲數據。
Mock對象的支持者認為，通過模擬EmployeeDAO，我們可以節約相當多的時間和精力，避免了建立和使用真實數據庫的開銷。Mock可以有效地加快單元測試的創建和執行過程，但是它們不能保證系統作為一個整體能夠正常運行。Mock可能會隱藏所模擬的協作軟件中的錯誤和缺陷。為了找到那些缺陷，我們需要在測試套件中包含集成測試。在本例中，測試系統使用數據庫存儲員工信息。Mock測試只能驗證EmployeeBO與EmployeeDAO 之間的交互是正確的——也就是說，EmployeeBO 僅僅在適宜時間從EmployeeBO 調用期望的方法。只有集成測試才能幫助我們發現問題，比如JDBC驅動程序和數據庫本身的bug，這些bug在應用程序走向產品時不應存在。
Mock為測試代碼帶來混亂和重復
下面的代碼使用 EasyMock 測試：EmployeeBO用EmployeeDAO存儲新員工信息和更新當前員工信息。
@Before public void setUp() {
mockEmployeeDAO = createMock(EmployeeDAO.class);
employeeBO = new EmployeeBO(mockEmployeeDAO);
employee = new Employee("Alex", "CA", "US");
}
文章來源于領測軟件測試網 http://www.kjueaiud.com/