摘要

　　編寫單元測試代碼是一件很困難的工作。大多數(shù)情況下，我們需要測試那些以前沒有編寫過的使用復雜的協(xié)作軟件（如數(shù)據(jù)庫，應(yīng)用程序服務(wù)器或軟件模塊）的代碼。我們可能還需要處理一些難以在測試環(huán)境下生成的條件。建立這些依賴關(guān)系可能需要相當長的時間，這抵消了其自動測試方面的優(yōu)勢。本文將著重介紹Mock Objects――來自XP社區(qū)的一項測試技術(shù)（XP社區(qū)提供了一種獨立的代碼測試，這種測試是通過模擬外部依賴來實現(xiàn)的）。和使用任何其它工具一樣，我們要謹慎，防止濫用。
Mock Objects概述

　　近些年來，開發(fā)人員又重新發(fā)現(xiàn)了自己編寫測試代碼的好處。他們認同，發(fā)現(xiàn)并修改軟件中的錯誤所付出的代價是昂貴的。結(jié)果，Unit Testing作為查找代碼錯誤和幫助確定系統(tǒng)需求的方法，成為了軟件開發(fā)流程中不可或缺的一部分。單元測試的主要目標是獨立地對每一個工作單元（通常是一個類）進行測試。獨立代碼測試是一件困難的工作，尤其是難以在測試中快速建立依賴關(guān)系的情況下。編寫和維護單元測試代碼的難度越大，開發(fā)人員越容易失去信心，并停止編寫測試代碼。

　　Tim Mackinnon、Steve Freeman和Philip Craig在他們的文章“Endo-Testing: Unit Testing with Mock Objects”中對Mock對象的基本概念進行了介紹，這篇文章發(fā)表在XP2000上。Mock對象（或Mock）模擬代價昂貴且難以使用的協(xié)作軟件，并提供了一種方法用于：

    在測試環(huán)境中建立復雜的依賴關(guān)系（例如，模擬數(shù)據(jù)庫連接，代替真正的數(shù)據(jù)庫連接）
    驗證測試行為是否符合期望結(jié)果（例如，驗證JDBC連接在使用結(jié)束后關(guān)閉――也是在特定時刻調(diào)用 java.sql.Connection中的 close方法）
    模擬難以生成的環(huán)境條件（例如，模擬JDBC驅(qū)動程序拋出的 SQLException 類）。

　　雖然很有用，但Mock并不是的，濫用Mock所帶來的壞處將會大于它為項目帶來的好處。
Mock的缺點

　　Mock程序員需要注意以下幾個問題。

Mock可能會隱藏集成問題

　　尤其是，如果我們只使用Mock進行代碼測試，而不編寫集成測試，則這種情況很可能發(fā)生。

　　請考慮圖1中的例子。

　　圖1.將新員工信息存儲于數(shù)據(jù)庫中

　　EmployeeBO類提供了與Employees有關(guān)的業(yè)務(wù)服務(wù)，并使用EmployeeDAO通過JDBC將數(shù)據(jù)持久存儲在關(guān)系數(shù)據(jù)庫中。測試EmployeeBO意味著建立一個數(shù)據(jù)庫，并用它來存儲數(shù)據(jù)。