UML软件工程组织

 

 

Mock Objects:缺点和用例

2008-06-20 作者:Alex Ruiz 来源:网络

 

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

Mock用例

另一方面,若使用得当,Mock对象会很有用。下面是Mock的一些好的用例。

提交修改之前的测试组合

在将本地的代码修改提交到代码控制存储库之前,为每个开发人员执行一次快速运行测试组合可以明显加快开发速度。只要测试能保证本地改变不会给代码基础带来错误,Mock对象就可以用来构建这种测试组合。一个典型的例子是,用HttpServletRequest、HttpServletResponse和HttpSession mock对象对Servlet进行独立测试,这比建立真正的应用程序服务器要更快速、更方便。

只要牢记这些测试可能会脆弱,我们就可以在测试套件中使用Mock,且有些时候(例如,在连续的集成创建过程中),我们也需要进行集成和功能测试。

对尚未编写的组件进行临时的集成测试

Mock对于各复杂组件在将来进行集成是非常有用的。例如,某个小组在等待另一个小组完成其组件时,就可以使用Mock测试,这是很有意义的。为了最小化集成中的问题,第二个小组可以为第一个小组构建并提供一个Mock对象。第二个小组完成了他们的工作,两个小组的组件集成测试就开始了,希望Mock测试使他们为实现系统预期行为,工作更密切。

到这一阶段,Mock已经实现了既定目标,并且应该将它移除(因为它存在潜在缺陷,甚至将来的测试还需要使用也是如此)。

装饰设计模式的测试实现

在前面的例子中,只要数据被正确存储,EmployeeBO怎样把员工信息存储到数据库中是无关紧要的。在装饰(decorator)设计模式中,它们与装饰对象之间的正确交互与交互的最终结果同样重要。考虑图3中所描述的简单例子。

图3 缓存管理系统的类图

图3演示了一个缓存管理系统,负责把经常使用的对象存储在缓存中,以提高系统的性能。这个缓存管理系统由一个接口(CacheManager)和两个实现(DistributedCacheManager和EmbeddedCacheManager)组成,这两个实现分别用于Web应用程序和富客户端应用程序。

假设需要引入一种配置方法,指导缓冲系统怎样处理Exceptions 。如果系统处于生产阶段,缓存系统中的错误应该不会终止系统的运行。换句话说,缓存系统抛出的任何Exception都应该忽略。另一方面,对于集成测试,我们需要获取缓存抛出的所有Exception,对它们进行诊断并修复缓存系统中的实现缺陷。

使用Decorator Pattern(装饰模式)可以很容易解决这个问题。我们能很容易地为任何CacheManager动态添加异常处理,作为一种灵活的继承替换方式。

public final class IgnoreExceptionsCacheManagerDecorator implements CacheManager {

private static final Object NULL = new Object();

private static Logger logger = Logger.getAnonymousLogger();

private final CacheManager decorated;

public IgnoreExceptionsCacheManagerDecorator(CacheManager decorated) {
this.decorated = decorated;
}
public Object getFromCache(String key) {
try {
return decorated.getFromCache(key);
} catch (Exception e) {
logger.log(SEVERE, "Unable to retrieve an object using key \"" + key + "\"", e);
}
return NULL;
}

public void putInCache(String key, Object o) {
try {
decorated.putInCache(key, o);
} catch (Exception e) {
logger.log(SEVERE, "Unable to store the object " + o + " using key \"" + key + "\"", e);
}
}
}

为了避免缓存系统中的任何错误导致产品中某些应用程序停止运行,我们仅需要使用IgnoreExceptionsCacheManagerDecorator :

CacheManager cacheManager = new IgnoreExceptionsCacheManagerDecorator(new DistributedCacheManager());

以下代码演示了如何使用Mock(和EasyMockTemplate)来测试IgnoreExceptionsCacheManagerDecorator :

public class IgnoreExceptionsCacheManagerDecoratorTest {

private IgnoreExceptionsCacheManagerDecorator decorator;
private CacheManager decoratedMock;

@Before public void setUp() {
decoratedMock = createMock(CacheManager.class);
decorator = new IgnoreExceptionsCacheManagerDecorator(decoratedMock);
}

@Test public void shouldNotPropagateExceptionFromCache() {
final String key = "name";
final RuntimeException exception = new RuntimeException();
EasyMockTemplate t = new EasyMockTemplate(decoratedMock) {

@Override protected void expectations() {
expect(decoratedMock.getFromCache(key)).andThrow(exception);
}

@Override protected void codeToTest() {
try {
decorator.getFromCache(key);
} catch (Exception e) {
if (e == exception) fail("Should not propagate exception thrown by the cache");
}
assertExceptionWasLogged(exception);
}
};
t.run();
}
}

在装饰模式例子中,Mock对象提供了良好的测试支持,因为:

  • Mock像装饰对象一样很容易使用
  • 使用Mock可以很容易地模拟缓存抛出的异常
  • 通过使用Mock,我们能验证装饰和被装饰对象之间的正确交互——即IgnoreExceptionsCacheManagerDecorator 的get(String, Object)方法调用被装饰对象的get(String, Object)方法。

实际上,当两个或更多对象之间的交互和这种交互的最终结果一样重要时,测试装饰是Mock测试许多应用中的一种。Mock的用法必须逐一确认(如测试Adapter模式的特定实现时)。装饰仅是安全引入Mock的一种特殊情况。

结束语

独立代码测试是一项具有挑战性的工作。通常,非平凡代码需要依赖一些协作软件,而这些协作软件是无法在测试中轻易或快速建立的。开发人员,甚至是最积极的开发人员,经过花费大量时间编写,维护和运行测试后都会失去信心。为了避免测试的减少,Mock对象提供了一种机制,通过模拟那些真实世界中的难以使用的和开销昂贵的依赖关系来进行完全独立的代码测试。虽然Mock能简化单元测试的创建,但它们不能代替功能测试和集成测试。Mock需要谨慎使用;滥用Mock会带来诸多问题,比如隐藏的集成问题、混乱、代码测试的重复、不必要的代码和测试的脆弱性。

 

组织简介 | 联系我们 |   Copyright 2002 ®  UML软件工程组织 京ICP备10020922号

京公海网安备110108001071号