使用Wiremock进行集成测试 - kubilay

作为Trendyol客户服务团队，我们开发和维护不同的项目。为了能够安全地依赖我们的项目并增加我们的交付重点，我们始终试图改善我们的运营。集成测试是这些操作步骤之一，最近我们有机会专注于我们的集成测试，并且情况有所改善。我将通过回答以下问题来尝试解释与集成测试过程相关的这些操作：

在Wiremock之前我们如何管理集成测试？
是什么问题促使我们使用Wiremock？
我们如何使用Wiremock？

首先，让我们深入了解“ Wiremock时代之前”。 在Wiremock时代之前 我们有2个不同的项目：

api-gateway：主要的Restful API项目。
api-gateway-test：使用Gherkin和Java的Cucumber集成测试项目。

回到CI / CD管道，以前，集成测试项目将通过向主项目的阶段实例发出请求来在其自己的CI管道上运行测试。这可能会导致几个问题，最重要的是环境依赖性。我所说的环境依赖性是，每当测试项目运行一个简单的场景（例如获取订单信息）时，它都会向gateway-api的stage实例发出请求。作为回报，gateway-api项目将运行已实现的业务，并且很可能会向另一个外部api的stage实例发出请求以获取请求的数据。 那么，有什么问题呢？ 乍一看，这种情况似乎并不成问题，但让我提示您几周（也许几天）后发生的情况。由于此外部api是阶段实例，因此将来相同请求的响应可能会给您一个404惊喜。因为，也许external-api的所有者团队正在进行DELETE端点测试并感到惊讶，所以他们删除了我们用来运行测试的订单信息。简而言之，该测试订单不再存在。这意味着某人必须找到合适的订单信息来修复测试。而且该命令在某个时候也不会存在。然后有人去解决。.我想您在这里看到我的意思，这是一个恶性循环，我们需要进行短跑。这是眼前的问题之一，还有另一个至关重要的问题。假设我们有100％的把握，只要我们想提出相同的请求，就会始终奇迹般地存在所请求的信息。超时和响应时间如何？ 在Wiremock时代之后 首先，让我们看一下Wiremock官方网站的基本定义： WireMock是基于HTTP的API的模拟器。有些人可能会认为它是服务虚拟化工具或模拟服务器。当您依赖的API不存在或不完整时，它可以使您保持生产力。它支持测试真实API无法可靠生成的极端情况和失败模式。而且由于速度很快，因此可以将构建时间从数小时缩短到数分钟。阅读定义后，您将意识到这很可能会解决前面提到的问题。它可以模拟所有这些超时失败案例，还可以为我们正在讨论的那些外部api提供模拟响应。这意味着Wiremock可以等待请求，并通过匹配请求来返回告诉我们要返回的内容，就好像它是我们的任何外部api一样。从现在开始，我们的集成测试项目不再负责运行测试。此步骤移至gateway-api项目的管道。现在，对于每个项目，管道的状态可以总结如下：

Gateway-api：Git推送->构建项目->将构建的Docker映像作为'gateway-api：latest'推送到Docker注册表
Gateway-test-api：Git推送->构建项目->将构建的Docker映像作为'gateway-api-test：latest'推送到Docker注册表

在我们放大“集成测试”步骤之前，最好先看一下使这些步骤成为可能的一些代码片段。这些文件之一是gateway-api的gitlab-ci.yml文件，它基本上是一个配置文件，用于管理项目的CI流程。

variables:
  REGISTRY_URL: <docker_registry_url>
  REGISTRY_PASS: <docker-registry-username> 
  REGISTRY_HOST: <docker-registry-password>

stages:
  - Integration test
  - Build

Build:
  stage: build
  script:
    - docker login -u $REGISTRY_USER -p $REGISTRY_PASS $REGISTRY_HOST
    - docker build -t greay-gw-api-build .
    - docker push great-gw-api-build

Integration Test:
  Integration test
  image: $REGISTRY_URL/docker-compose-git
  services:
    - $REGISTRY_URL/docker-dind
  variables:
    DOCKER_HOST: $REGISTRY_URL
  script:
    - docker login -u $REGISTRY_USER -p $REGISTRY_PASS $REGISTRY_HOST
    - docker-compose up --abort-on-container-exit

本质上，此配置文件使两件事连续发生：

构建最新的映像并将其推送到指定的注册表。
如果docker-compose文件存在于同一目录中，请运行该文件。（我们将很快通过示例深入研究此流程。）

这个gitlab-ci文件和网关-api-test项目中的文件有一个区别。集成测试项目不会运行集成测试，因此该项目的gitlab-ci文件中不存在“集成测试”阶段。总结到现在为止发生的所有事情：

我们在gateway-api中实现了某种功能，并将其合并到master分支中。合并之后，带有“：latest”标签的docker映像将被推送到相应的注册表。
我们还针对该功能编写了集成测试，还将其合并到master分支，这再次导致带有“：latest”标签的测试项目的docker映像被推送到相应的注册表。

如果您仍在跟上现状，那么著名的“集成测试”步骤就来了。更详细点击标题见原文