契约测试

使用测试替身的最常见情况之一是与外部服务进行通信。通常，此类服务由不同的团队维护，它们可能受到缓慢和不可靠的网络的影响，本身也可能不可靠。这就是测试替身很方便的原因，它可以防止您自己的测试变慢和不可靠。但是，针对替身进行测试总是会引发一个问题，即替身是否确实是外部服务的准确表示，以及如果外部服务更改其契约会发生什么？

解决此问题的一个好方法是继续针对替身运行您自己的测试，但除了定期运行一组单独的契约测试。这些测试检查对测试替身的所有调用是否返回与对外部服务的调用相同的結果。任何契约测试的失败都意味着您需要更新测试替身，并且可能需要更新您的代码以考虑服务契约更改。

这些测试不需要作为您常规部署管道的一部分运行。您的常规管道基于您代码更改的节奏，但这些测试需要基于外部服务更改的节奏。通常每天运行一次就足够了。

契约测试的失败不一定会像普通测试失败那样中断构建。但是，它应该触发一项任务以使一切恢复一致。这可能涉及更新测试和代码以使它们与外部服务保持一致。同样有可能，它将触发与外部服务维护者进行对话，以讨论更改并提醒他们他们的更改如何影响其他应用程序。

如果此服务用作生产应用程序的一部分，则与外部服务供应商的这种沟通更加重要。在这些情况下，契约更改可能会破坏生产应用程序，从而触发紧急修复并与供应商团队进行紧急对话。

为了减少契约意外中断的可能性，将迁移到消费者驱动契约方法很有用。您可以通过让供应商团队拥有契约测试的副本来促进这一点，以便他们可以在其构建管道中运行这些测试。

在测试此类外部服务时，通常最好针对外部服务的测试实例进行测试。偶尔，您别无选择，只能访问生产实例，此时您需要与供应商联系，让他们知道正在发生的事情，并格外小心测试的操作。

契约测试检查外部服务调用的契约，但不一定检查确切的数据。通常，存根会将响应快照到特定日期，因为数据格式比实际数据更重要。在这种情况下，契约测试需要检查格式是否相同，即使实际数据已更改。

构建这些测试替身的最佳方法之一是使用自初始化假货.