外部集成网页制作_外部服务的集成测试

外部集成网页制作

我们的系统通常依赖于第三方服务（它们甚至可能是我们无法控制的公司内部服务）。此类服务包括公开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 + "*")));
}

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

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

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