模拟对象不是存根

常规测试

我将从一个简单的例子开始说明这两种风格。（这个例子是用 Java 编写的，但这些原理对任何面向对象的语言都有意义。）我们想要获取一个订单对象并从一个仓库对象中填充它。订单非常简单，只有一个产品和数量。仓库保存着不同产品的库存。当我们要求订单从仓库中填充自己时，有两种可能的响应。如果仓库中有足够的商品来填充订单，则订单将被填充，仓库中该商品的数量将减少相应的数量。如果仓库中没有足够的商品，则订单不会被填充，仓库中也不会发生任何变化。

这两种行为意味着几个测试，这些测试看起来非常像传统的 JUnit 测试。

public class OrderStateTester extends TestCase {
  private static String TALISKER = "Talisker";
  private static String HIGHLAND_PARK = "Highland Park";
  private Warehouse warehouse = new WarehouseImpl();

  protected void setUp() throws Exception {
    warehouse.add(TALISKER, 50);
    warehouse.add(HIGHLAND_PARK, 25);
  }
  public void testOrderIsFilledIfEnoughInWarehouse() {
    Order order = new Order(TALISKER, 50);
    order.fill(warehouse);
    assertTrue(order.isFilled());
    assertEquals(0, warehouse.getInventory(TALISKER));
  }
  public void testOrderDoesNotRemoveIfNotEnough() {
    Order order = new Order(TALISKER, 51);
    order.fill(warehouse);
    assertFalse(order.isFilled());
    assertEquals(50, warehouse.getInventory(TALISKER));
  }

xUnit 测试遵循典型的四阶段序列：设置、执行、验证、拆卸。在本例中，设置阶段部分在 setUp 方法（设置仓库）中完成，部分在测试方法（设置订单）中完成。对 order.fill 的调用是执行阶段。这是对对象进行操作以执行我们想要测试的操作的地方。然后断言语句是验证阶段，检查执行的方法是否正确执行了其任务。在本例中，没有显式的拆卸阶段，垃圾收集器会为我们隐式地执行此操作。

在设置期间，我们组合了两种类型的对象。Order 是我们正在测试的类，但为了使 Order.fill 工作，我们还需要一个 Warehouse 的实例。在这种情况下，Order 是我们关注测试的对象。面向测试的人喜欢使用诸如被测对象或被测系统之类的术语来命名这样的东西。这两个术语都是难听的，但由于它是一个被广泛接受的术语，我将忍住鼻子使用它。遵循 Meszaros 的说法，我将使用被测系统，或者更确切地说，使用缩写 SUT。

因此，对于此测试，我需要 SUT（Order）和一个协作者（warehouse）。我需要仓库有两个原因：一是让测试的行为正常工作（因为 Order.fill 调用仓库的方法），二是需要它进行验证（因为 Order.fill 的结果之一可能是仓库状态的潜在变化）。当我们进一步探讨这个主题时，您会看到我们会对 SUT 和协作者之间的区别进行很多讨论。（在这篇文章的早期版本中，我将 SUT 称为“主要对象”，将协作者称为“次要对象”）

这种测试风格使用 **状态验证**：这意味着我们通过检查方法执行后 SUT 及其协作者的状态来确定执行的方法是否正常工作。正如我们将看到的，模拟对象能够实现不同的验证方法。

使用模拟对象的测试

现在，我将使用模拟对象来执行相同的行为。对于这段代码，我使用 jMock 库来定义模拟对象。jMock 是一个 Java 模拟对象库。还有其他模拟对象库，但这个库是该技术的创始人编写的最新库，因此它是一个很好的入门库。

public class OrderInteractionTester extends MockObjectTestCase {
  private static String TALISKER = "Talisker";

  public void testFillingRemovesInventoryIfInStock() {
    //setup - data
    Order order = new Order(TALISKER, 50);
    Mock warehouseMock = new Mock(Warehouse.class);
    
    //setup - expectations
    warehouseMock.expects(once()).method("hasInventory")
      .with(eq(TALISKER),eq(50))
      .will(returnValue(true));
    warehouseMock.expects(once()).method("remove")
      .with(eq(TALISKER), eq(50))
      .after("hasInventory");

    //exercise
    order.fill((Warehouse) warehouseMock.proxy());
    
    //verify
    warehouseMock.verify();
    assertTrue(order.isFilled());
  }

  public void testFillingDoesNotRemoveIfNotEnoughInStock() {
    Order order = new Order(TALISKER, 51);    
    Mock warehouse = mock(Warehouse.class);
      
    warehouse.expects(once()).method("hasInventory")
      .withAnyArguments()
      .will(returnValue(false));

    order.fill((Warehouse) warehouse.proxy());

    assertFalse(order.isFilled());
  }

首先关注 testFillingRemovesInventoryIfInStock，因为我在后面的测试中做了一些捷径。

首先，设置阶段非常不同。首先，它分为两个部分：数据和期望。数据部分设置了我们感兴趣的要处理的对象，从这个意义上说，它类似于传统的设置。不同之处在于创建的对象。SUT 是一样的——一个订单。但是协作者不是仓库对象，而是一个模拟仓库——技术上是类 Mock 的实例。

设置的第二部分在模拟对象上创建期望。期望指示在执行 SUT 时应在模拟对象上调用哪些方法。

一旦所有期望都到位，我就执行 SUT。在执行之后，我进行验证，验证有两个方面。我对 SUT 运行断言——与之前一样。但是，我还验证模拟对象——检查它们是否按预期被调用。

这里的关键区别在于我们如何验证订单在与仓库的交互中是否做了正确的事情。使用状态验证，我们通过对仓库状态进行断言来实现这一点。模拟对象使用 **行为验证**，我们改为检查订单是否对仓库进行了正确的调用。我们通过在设置期间告诉模拟对象预期什么，并在验证期间要求模拟对象验证自己来进行此检查。只有订单使用断言进行检查，如果方法没有改变订单的状态，则根本没有断言。

在第二个测试中，我做了一些不同的事情。首先，我使用 mock 方法在 MockObjectTestCase 中创建模拟对象，而不是使用构造函数。这是 jMock 库中的一个便利方法，这意味着我不需要在以后显式地调用 verify，使用便利方法创建的任何模拟对象都会在测试结束时自动验证。我也可以在第一个测试中这样做，但我希望更明确地展示验证，以展示使用模拟对象进行测试的工作原理。

第二个测试用例中的第二个不同之处是我使用 withAnyArguments 放宽了对期望的约束。这样做的原因是第一个测试检查了数字是否传递给仓库，因此第二个测试不需要重复测试的这一部分。如果订单的逻辑需要稍后更改，那么只有一个测试会失败，从而减轻了迁移测试的工作量。事实证明，我可以完全省略 withAnyArguments，因为它是默认值。

public class OrderEasyTester extends TestCase {
  private static String TALISKER = "Talisker";
  
  private MockControl warehouseControl;
  private Warehouse warehouseMock;
  
  public void setUp() {
    warehouseControl = MockControl.createControl(Warehouse.class);
    warehouseMock = (Warehouse) warehouseControl.getMock();    
  }

  public void testFillingRemovesInventoryIfInStock() {
    //setup - data
    Order order = new Order(TALISKER, 50);
    
    //setup - expectations
    warehouseMock.hasInventory(TALISKER, 50);
    warehouseControl.setReturnValue(true);
    warehouseMock.remove(TALISKER, 50);
    warehouseControl.replay();

    //exercise
    order.fill(warehouseMock);
    
    //verify
    warehouseControl.verify();
    assertTrue(order.isFilled());
  }

  public void testFillingDoesNotRemoveIfNotEnoughInStock() {
    Order order = new Order(TALISKER, 51);    

    warehouseMock.hasInventory(TALISKER, 51);
    warehouseControl.setReturnValue(false);
    warehouseControl.replay();

    order.fill((Warehouse) warehouseMock);

    assertFalse(order.isFilled());
    warehouseControl.verify();
  }
}

模拟对象和存根的区别

当模拟对象首次被引入时，许多人很容易将它们与使用存根的常见测试概念混淆。从那时起，人们似乎更好地理解了它们之间的区别（我希望本文的早期版本有所帮助）。但是，要完全理解人们使用模拟对象的方式，重要的是要了解模拟对象和其他类型的测试替身。（“替身”？如果您对这个词不熟悉，请不要担心，再等几段，一切都会变得清晰。）

当您进行这种测试时，您一次只关注软件的一个元素——因此有常见的术语单元测试。问题是，为了使单个单元正常工作，您通常需要其他单元——因此需要在我们的示例中使用某种仓库。

在我上面展示的两种测试风格中，第一种情况使用的是真实的仓库对象，第二种情况使用的是模拟仓库，当然这不是真实的仓库对象。使用模拟对象是在测试中不使用真实仓库的一种方法，但还有其他形式的非真实对象用于这种测试。

讨论此问题的词汇很快就会变得混乱——各种各样的词语都被使用：存根、模拟、伪造、虚拟。对于本文，我将遵循 Gerard Meszaros 的书中的词汇。这不是每个人都使用的词汇，但我认为这是一个很好的词汇，因为这是我的文章，我可以选择使用哪些词语。

Meszaros 使用 **测试替身** 作为通用术语，用于指代任何类型的假对象，用于代替真实对象进行测试。这个名字来源于电影中替身演员的概念。（他的目标之一是避免使用任何已经被广泛使用的名称。）然后 Meszaros 定义了五种特定的替身类型

• **虚拟** 对象被传递，但实际上从未使用过。通常，它们只是用来填充参数列表。
• **伪造** 对象实际上有工作实现，但通常会采取一些捷径，使其不适合生产（内存数据库 就是一个很好的例子）。
• **存根** 为测试期间的调用提供预先录制好的答案，通常对测试中未编程的任何内容都不响应。
• **间谍** 是记录一些信息的存根，这些信息基于它们被调用的方式。一种形式可能是记录发送了多少条消息的电子邮件服务。
• 模拟对象 是我们在这里讨论的：预先编程了期望的对象，这些期望构成了对它们预期接收的调用的规范。

在这些类型的替身中，只有模拟对象坚持行为验证。其他替身可以使用，通常也使用状态验证。模拟对象在练习阶段的行为实际上与其他替身类似，因为它们需要让 SUT 相信它正在与真正的协作者进行通信 - 但模拟对象在设置和验证阶段有所不同。

为了更深入地探讨测试替身，我们需要扩展我们的示例。许多人只在真实对象难以使用时才使用测试替身。测试替身更常见的情况是，如果我们说如果我们无法完成订单，我们想发送一封电子邮件。问题是我们不想在测试期间向客户发送实际的电子邮件。因此，我们创建了电子邮件系统的测试替身，我们可以控制和操作它。

在这里，我们可以开始看到模拟对象和存根之间的区别。如果我们正在为这种邮件行为编写测试，我们可能会编写一个简单的存根，如下所示。

public interface MailService {
  public void send (Message msg);
}

public class MailServiceStub implements MailService {
  private List<Message> messages = new ArrayList<Message>();
  public void send (Message msg) {
    messages.add(msg);
  }
  public int numberSent() {
    return messages.size();
  }
}                                 

然后，我们可以对存根使用状态验证，如下所示。

class OrderStateTester...

  public void testOrderSendsMailIfUnfilled() {
    Order order = new Order(TALISKER, 51);
    MailServiceStub mailer = new MailServiceStub();
    order.setMailer(mailer);
    order.fill(warehouse);
    assertEquals(1, mailer.numberSent());
  }

当然，这是一个非常简单的测试 - 只是发送了一条消息。我们没有测试它是否发送给了正确的人，或者内容是否正确，但这足以说明问题。

使用模拟对象，此测试看起来会有很大不同。

class OrderInteractionTester...

  public void testOrderSendsMailIfUnfilled() {
    Order order = new Order(TALISKER, 51);
    Mock warehouse = mock(Warehouse.class);
    Mock mailer = mock(MailService.class);
    order.setMailer((MailService) mailer.proxy());

    mailer.expects(once()).method("send");
    warehouse.expects(once()).method("hasInventory")
      .withAnyArguments()
      .will(returnValue(false));

    order.fill((Warehouse) warehouse.proxy());
  }
}

在这两种情况下，我都在使用测试替身而不是真实的邮件服务。区别在于存根使用状态验证，而模拟对象使用行为验证。

为了对存根使用状态验证，我需要在存根上添加一些额外的帮助验证的方法。因此，存根实现了 MailService，但添加了额外的测试方法。

模拟对象始终使用行为验证，存根可以使用任何一种方式。Meszaros 将使用行为验证的存根称为测试间谍。区别在于替身运行和验证的方式，我会留给你自己去探索。

经典测试和模拟测试

现在我到了可以探索第二个二分法的阶段：经典 TDD 和模拟 TDD 之间的区别。这里最大的问题是何时使用模拟对象（或其他替身）。

经典 TDD 风格是尽可能使用真实对象，如果使用真实对象很麻烦，就使用替身。因此，经典 TDD 会使用真实的仓库和邮件服务的替身。替身的类型并不重要。

然而，模拟 TDD 实践者将始终对任何具有有趣行为的对象使用模拟对象。在这种情况下，仓库和邮件服务都是如此。

尽管各种模拟框架都是针对模拟测试设计的，但许多经典测试者发现它们对于创建替身很有用。

模拟风格的一个重要分支是行为驱动开发 (BDD)。BDD 最初由我的同事 Daniel Terhorst-North 开发，作为一种帮助人们更好地学习测试驱动开发的技术，其重点是 TDD 作为一种设计技术的运作方式。这导致将测试重命名为行为，以更好地探索 TDD 在思考对象需要做什么方面提供的帮助。BDD 采用模拟方法，但它在此基础上进行了扩展，包括其命名风格以及将分析集成到其技术中的愿望。我在这里不再赘述，因为与本文相关的唯一之处在于 BDD 是 TDD 的另一种变体，它倾向于使用模拟测试。我会留给你点击链接获取更多信息。

你有时会看到“底特律”风格用于“经典”，而“伦敦”风格用于“模拟”。这暗指 XP 最初是在底特律的 C3 项目中开发的，而模拟风格是由伦敦的早期 XP 采用者开发的。我还应该提到，许多模拟 TDD 测试者不喜欢这个术语，事实上，他们不喜欢任何暗示经典测试和模拟测试之间存在不同风格的术语。他们认为，经典测试和模拟测试之间没有必要区分。

在差异之间进行选择

在这篇文章中，我解释了两种差异：状态或行为验证 / 经典或模拟 TDD。在做出这些选择时，需要牢记哪些论点？我将从状态与行为验证的选择开始。

首先要考虑的是上下文。我们是在考虑简单的协作，例如订单和仓库，还是复杂的协作，例如订单和邮件服务？

如果这是一个简单的协作，那么选择就很简单。如果我是一个经典 TDD 测试者，我不会使用模拟对象、存根或任何类型的替身。我使用真实对象和状态验证。如果我是一个模拟 TDD 测试者，我使用模拟对象和行为验证。根本不需要做任何决定。

如果这是一个复杂的协作，那么如果我是一个模拟 TDD 测试者，就不需要做任何决定 - 我只使用模拟对象和行为验证。如果我是一个经典 TDD 测试者，那么我确实需要做出选择，但这并不重要。通常，经典 TDD 测试者会根据具体情况做出决定，为每种情况选择最简单的路线。

因此，正如我们所见，状态与行为验证通常不是一个重大的决定。真正的问题在于经典 TDD 和模拟 TDD 之间。事实证明，状态和行为验证的特征确实会影响这种讨论，而这将是我投入大部分精力的地方。

但在这样做之前，让我提一下一个边缘情况。偶尔你会遇到一些很难使用状态验证的东西，即使它们不是复杂的协作。一个很好的例子是缓存。缓存的全部意义在于你无法从其状态判断缓存命中还是未命中 - 这种情况，即使对于最硬核的经典 TDD 测试者来说，行为验证也是明智的选择。我相信在两个方向上都存在其他例外情况。

当我们深入研究经典/模拟选择时，需要考虑很多因素，因此我将它们分成几个粗略的组。

那么我应该成为古典主义者还是模拟主义者？

我发现这个问题很难自信地回答。我个人一直都是老式的经典 TDD 支持者，到目前为止，我还没有看到任何改变的理由。我没有看到模拟 TDD 有任何令人信服的优势，并且担心将测试与实现耦合的后果。

当我观察模拟程序员时，这一点尤其令我印象深刻。我真的很喜欢编写测试时，您专注于行为的结果，而不是如何完成它。模拟测试人员一直在思考 SUT 将如何实现，以便编写期望。这对我的感觉真的很不自然。

我也有没有在除玩具以外的任何东西上尝试模拟 TDD 的劣势。正如我从测试驱动开发本身中学到的那样，在没有认真尝试的情况下，很难判断一种技术。我知道许多优秀的开发人员非常高兴并且是坚定的模拟测试支持者。因此，虽然我仍然是坚定的经典测试支持者，但我更愿意尽可能公平地陈述两种观点，以便您可以自己做出决定。

因此，如果模拟测试听起来对您有吸引力，我建议您尝试一下。如果您在模拟 TDD 旨在改进的一些领域遇到问题，那么尤其值得尝试。我认为这里有两个主要领域。一个是，如果您在测试失败时花费大量时间进行调试，因为它们没有干净地中断并告诉您问题出在哪里。（您也可以通过对更细粒度的集群使用经典 TDD 来改进这一点。）第二个领域是，如果您的对象没有包含足够的行为，模拟测试可能会鼓励开发团队创建更多行为丰富的对象。

最后的想法

随着人们对单元测试、xunit 框架和测试驱动开发的兴趣不断增长，越来越多的人开始使用模拟对象。许多时候，人们只是学习了一些关于模拟对象框架的知识，而没有完全理解支撑它们的模拟/经典分界线。无论您倾向于哪一边，我认为了解这种观点差异都是有用的。虽然您不必是模拟测试人员才能发现模拟框架很方便，但了解指导许多软件设计决策的思维方式是有用的。

本文的目的是指出这些差异，并阐述它们之间的权衡。模拟思维比我所能讨论的要多，尤其是它对设计风格的影响。我希望在未来几年，我们能看到更多关于这方面的文章，这将加深我们对在代码之前编写测试的迷人后果的理解。