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

  @Test public void shouldAddNewEmployee() {
    mockEmployeeDAO.insert(employee);
    replay(mockEmployeeDAO);
    employeeBO.addNewEmployee(employee);
    verify(mockEmployeeDAO);
  }

  @Test public void shouldUpdateEmployee() {
    mockEmployeeDAO.update(employee);
    replay(mockEmployeeDAO);
    employeeBO.updateEmployee(employee);
    verify(mockEmployeeDAO);
  }

      测试方法shouldAddNewEmployee用于验证测试对象（employeeBO ）和Mock（mockEmployeeDAO ）之间交互是否正确。它期望employeeBO调用mockEmployeeDAO中的insert方法，并将接收到的Employee实例传递给该方法。shouldAddNewEmployee方法虽然简单，但其中含有一些没有实际目的的代码，这为我们的测试带来了混乱：

• 重复调用replay，通知EasyMock所有期望的工作已完成。
• 重复调用verify，通知EasyMock所有期望的工作已验证完成。

    Mock的使用常常遵循下面的模式：

• 建立Mock和期望
• 执行要测试的代码
• 验证执行结果是否符合期望

    这种模式会在测试代码中引入重复，这在测试方法shouldAddNewEmployee()和shouldUpdateEmployee()中很明显。使用 EasyMockTemplate 可以减少代码混乱和重复：

/**
 * Understands a template for usage of EasyMock mocks.
 * @author Alex Ruiz
 */
public abstract class EasyMockTemplate {

  /** Mock objects managed by this template */
  private final List<Object> mocks = new ArrayList<Object>();

  /**
   * Constructor.
   * @param mocks the mock objects this template will manage.
   * @throws IllegalArgumentException if the list of mock objects is null or empty.
   * @throws IllegalArgumentException if the list of mock objects contains a null value.
   */
  public EasyMockTemplate(Object... mocks) {
    if (mocks == null) throw new IllegalArgumentException("The list of mock objects should not be null");
    if (mocks.length == 0) throw new IllegalArgumentException("The list of mock objects should not be empty");
    for (Object mock : mocks) {
      if (mock == null) throw new IllegalArgumentException("The list of mocks should not include null values");
      this.mocks.add(mock);
    }
  }

  /**
   * Encapsulates the common pattern followed when using EasyMock.
   * <ol>
   * <li>Set up expectations on the mock objects</li>
   * <li>Set the state of the mock controls to "replay"</li>
   * <li>Execute the code to test</li>
   * <li>Verify that the expectations were met</li>
   * </ol>
   * Steps 2 and 4 are considered invariant behavior while steps 1 and 3 should be implemented by subclasses of this template.
   */
  public final void run() {
    setUp();
    expectations();
    for (Object mock : mocks) replay(mock);
    codeToTest();
    for (Object mock : mocks) verify(mock);
  }

  /** Sets the expectations on the mock objects. */
  protected abstract void expectations();

  /** Executes the code that is under test. */
  protected abstract void codeToTest();

  /** Sets up the test fixture if necessary. */
  protected void setUp() {}
}

    现在，我们使用EasyMockTemplate重新建立测试：

  @Test public void shouldAddNewEmployee() {
    EasyMockTemplate t = new EasyMockTemplate(mockEmployeeDao) {
      @Override protected void expectations() {
        mockEmployeeDAO.insert(employee);
      }

      @Override protected void codeToTest() {
        employeeBO.addNewEmployee(employee);
      }
    };
    t.run();
  }

  @Test public void shouldUpdateEmployee() {
    EasyMockTemplate t = new EasyMockTemplate(mockEmployeeDao) {
      @Override protected void expectations() {
        mockEmployeeDAO.update(employee);
      }

      @Override protected void codeToTest() {
        employeeBO.updateEmployee(employee);
      }
    };
    t.run();
  }

　　EasyMockTemplate可以带来以下优点：

• 因expectations和codeToTest方法是抽象的，故EasyMockTemplate会强制开发人员指定期望结果和要测试的代码，从而减少程序错误。
• 可以明确区分期望结果和要测试的代码，这使测试更容易理解和维护。
• 避免了代码重复，因为我们不必再去调用replay和verify方法了。

    您可以从 此处 下载EasyMockTemplate的最新版本。

    Mock测试可能是脆弱的
    Mock测试属于白盒测试，它需要非常熟悉类的内部知识。这是Mock交互特性的副作用。对方法实现的合理修改可能会破坏使用Mock的测试，即便这种方法的运行结果是相同的。
    在本例中，EmployeeBO将与EmployeeDAO交互，并使用简单JDBC将员工信息存储于数据库中。假设我们改变了在数据库中存储信息的方式——比如说，将JDBC改为JPA——使用EmployeeJPA替换EmployeeDAO，并在相同的数据库表中存储相同的信息。我们期望已有测试会通过，因为输出（将数据存储在数据库中）没有改变。遗憾的是，我们的测试将以失败告终，因为EmployeeBO和EmployeeDAO之间的交互已经不复存在：现在，EmployeeBO将使用EmployeeJPA在数据库中存储数据，如图2所示。

图2 改变数据库持久性策略破坏了当前的Mock测试

    相反，只要系统内部改变的同时输出不改变，黑盒测试（如功能测试）则很少会遭到破坏，因为这种测试仅仅基于系统需求的知识。
    在本例中，集成测试用于验证存储于数据库中的数据是否正确性，而不是验证数据是否存储在数据库中。将EmployeeDAO替换成EmployeeJPA后，集成测试就不会失败。

    模拟具体的类会很危险
    一些Mock对象框架（如EasyMock和JMock）提供了一些扩展，这些扩展使用了cglib。通过类的继承和方法覆盖，cglib可以在运行为特定的类生成代理。因此，要模拟的类和涉及的方法都不是最终方案，这限制了我们的设计决策。
    同时，在实例化一个基于类的Mock时，需要使用具体的构造函数签名将构造函数绑定与一个或多个测试耦合在一起。从而，Mock类将难以维护，而测试甚至会更加脆弱，因为当映射存在时，代码重构不是件小事，甚至用现代的Java IDE也是如此。
    通常，基于interfaces的Mock在公共API上建立其期望结果，这或多或少是比较稳定的。相反，基于类的Mock的期望结果也许需要依靠保护类型的方法，该方法代表类的实现细节。可以随时对这些实现细节进行修改，改变要测试的代码与Mock之间的交互，从而增加了破坏当前测试的可能性。

    Mock可能会导致interface 滥用
    滥用Mock可能会产生一种副作用，即创建不必要的Java interfaces，其目的为了创建Mock（尽量避免基于类的Mock的问题）。典型例子包括创建有且仅有一个实现的interfaces，比如工具类和帮助类。这种做法的依据常常来自对“编写接口，而不是具体实现它们”原则的错误理解。这一原则提到了接口的概念，接口是一个超类，它利用了多态性，而不是Java结构interface。可以使用Java interface或抽象类来实现接口。
    创建interfaces来帮助mock测试会增加维护开销（因为有更多的代码需要维护），这常常盖过mock测试所带来的好处。