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