不要模拟（ Mock ）不属于你负责的组件！

本文将讨论如何以及在什么地方应该使用 Mock 技术来模拟第三方库或外部组件。

虽然对外部组件的模拟（ Mocks ）让你能够验证系统的边界，而不必真正使用外部系统。但是，它也创建了一个不自然且有可能偏离了真实代码的机会，引入测试风险。

下面的测试代码就使用了 Mock 技术来模拟第三方库。

这么做，可能会引发什么样的问题呢？

// Mock a salary payment library
@Mock SalaryProcessor mockSalaryProcessor;
@Mock TransactionStrategy mockTransactionStrategy;
...
when(mockSalaryProcessor.addStrategy()).thenReturn(mockTransactionStrategy);
when(mockSalaryProcessor.paySalary()).thenReturn(TransactionStrategy.SUCCESS);
MyPaymentService myPaymentService = new MyPaymentService(mockSalaryProcessor);
assertThat(myPaymentService.sendPayment()).isEqualTo(PaymentStatus.SUCCESS);

模拟你无权掌控的类型会让测试维护工作更困难：

• 第三方库的升级变得更困难：通常在 Mock 中硬编码了某个 API 的预期返回值，而这个值有可能被我们写错了，也可能随时间而过时。当升级第三方库的新版本时，手动更新测试例也需要花大量时间。

在上面的示例中，当一个新版本修改了“ addStrategy() ”，使其可以返回一个从“TransactionStrategy”派生出来的新类（例如“ SalaryStrategy ”）。即便被测试代码根本不需要修改（因为它仍旧是引用 TransactionStrategy ），可为了自动化测试能够成功，你还是要去修改你的 Mock 。

• 很难知道第三方库的更新是否在你的代码中引入了 bug：随着第三方库的变更，你在 Mock 中所内置的原定假设可能过时了，因此导致：即使在被测代码有 bug 的情况下，测试也能成功通过。

在上面的示例中，如果第三方库将“ payalary() ”改为返回 TransactionStrategy.SCHEDULED ，由于被测代码未正确处理此返回值，就可能会引入错误。然而，作为使用这个第三方库的人，你可能并没接到变更通知。由于 Mock 不会返回这个新的值，所以你的测试代码仍旧成功执行。

所以，尽量不要使用 Mock ，而尽可能使用真实的实现代码。如果行不通的话，至少也应该使用由第三方库维护者所提供的伪实现（ fake implimetation ）。这会减少上面列出使用 Mock 所带来的维护成本，因为我们使用了真实的实现，上面由于 Mock 带来的维护问题不会发生。例如：

FakeSalaryProcessor fakeProcessor = new FakeSalaryProcessor(); // Designed for tests
MyPaymentService myPaymentService = new MyPaymentService(fakeProcessor);
assertThat(myPaymentService.sendPayment()).isEqualTo(PaymentStatus.SUCCESS);

如果你既不能使用真实的实现，也没有伪实现（ 第三方库的维护者没有为你创建一个 fake implementation ），那么，你就要自己创建一个 wrapper 类来模拟 （Mock） 它了。虽然这并不很理想，但通过避免依赖于第三方库 API 的 Mock，也是可以减少一些维护负担。例如：

@Mock MySalaryProcessor mockMySalaryProcessor; // Wraps the SalaryProcessor library
...
// Mock the wrapper class rather than the library itself
when(mockMySalaryProcessor.sendSalary()).thenReturn(PaymentStatus.SUCCESS);

MyPaymentService myPaymentService = new MyPaymentService(mockMySalaryProcessor);
assertThat(myPaymentService.sendPayment()).isEqualTo(PaymentStatus.SUCCESS);

为了避免上面列出的问题，我们更愿意使用对真实实现的调用来测试 Wrapper 类。这样，使用实际实现进行测试的缺点（例如，测试运行时间较长）就被限制在这个 Wrapper 类的测试上，而不是整个代码库的测试。

“不要模拟（ Mock ）不属于你负责的组件！” 也在 Steve Freeman 和 Nat Pryce 写的 《Growing Object Oriented Software, Guided by Tests》一书中提到了。更多关于过度使用 Mocks 的缺点（甚至你自己的负责的类）可参见 这里.

如果你不想那么麻烦，也可以使用简单使用下面的方式初步判断一下。但是，由于它将问题过于简化了，所以仅作为参考。

原文作者：Stefan Kennedy and Andrew Trenk

原文链接：Don’t Mock Types You Don’t Own

发表时间：July 16, 2020