摘要

　　编写单元测试代码是一件很困难的工作。大多数情况下，我们需要测试那些以前没有编写过的使用复杂的协作软件（如数据库，应用程序服务器或软件模块）的代码。我们可能还需要处理一些难以在测试环境下生成的条件。建立这些依赖关系可能需要相当长的时间，这抵消了其自动测试方面的优势。本文将着重介绍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意味着建立一个数据库，并用它来存储数据。