外部服务的集成测试

我们的系统通常依赖于第三方服务（它们甚至可能是我们无法控制的公司内部服务）。此类服务包括公开API的社交网络，带有诸如Salesforce，身份验证提供程序之类的API的SaaS或我们系统与之通信但不在产品生命周期内的任何系统。

在常规的集成测试中，我们将对所有子系统进行集成部署，以测试它们如何协同工作。但是，在使用外部服务的情况下，我们只能使用实际部署（考虑到一些API凭据）。我们必须编写集成测试哪些选项，即检查我们的系统是否与外部系统正确集成？

如果该服务提供了一个沙箱，那就是要走的路–您可以在目标环境中执行任何操作，并且该环境将短暂存在，并且对任何最终用户都不可见。但是，这很罕见，因为大多数外部服务都不提供此类沙箱。

另一个选择是拥有一个集成测试帐户-例如，您在Twitter上注册一个名为“您的产品测试”的应用程序，创建一个测试Twitter帐户，并将这些凭据提供给集成测试。如果您没有涉及多步交互和很多前提条件的复杂场景，那将很好用。例如，如果您的应用程序在一段时间内分析推文，则您过去无法使用测试帐户发布推文。

第三种选择是模拟。通常，模拟和集成测试是互斥的，但在这种情况下不是互斥的。您不想测试外部服务是否符合其规范（或API文档），而是想测试您的应用程序是否以适当的方式调用了它，并正确地处理了它的响应。因此，可以运行外部系统的模拟程序，该模拟程序以预定义的标准集返回预定义的结果。这些结果和标准应直接符合规格。

这可以通过运行嵌入式模拟服务器轻松实现。有多种工具可用于执行此操作-以下是其中一些Java列表-WireMock ， MockServer ， MockWebServer ， Apache Wink 。前三个是为上述用例专门创建的，而Apache Wink具有一个简单的模拟服务器类，作为较大项目的一部分。

因此，如果要测试每次成功购买后应用程序是否正确发布了推文，则可以（例如，使用WireMock）执行以下操作：

@Rule
public WireMockRule wireMockRule = new WireMockRule(8089);@Test
public void purchaseTweetTest() {stubFor(post(urlEqualTo("/statuses/update.json")).willReturn(aResponse().withStatus(200).withHeader("Content-Type", "application/json").withBody(getMockJsonResponse()));// ...purchaseService.completePurchase(purchase);verify(postRequestedFor(urlMatching("/statuses/update.json")).withRequestBody(matching(".*purchaseId: " + purchaseId + "*")));
}

这样，您将验证与外部服务的通信在您的应用程序中是否得到正确处理，即您是否正确集成，但不会在实际系统上进行测试。

当然，这有一个缺点–您在模拟程序中放置的规则可能与外部系统中的规则不同。您可能会误解了规范/文档，或者可能未涵盖所有特殊情况。但是为了进行自动化测试，我认为这比支持无法正确清理或设置测试数据的测试帐户更好。

这些自动集成测试可以与在暂存环境中进行手动测试相结合，以确保即使在实际的外部系统中集成也可以正常工作。