使用Wiremock进行集成测试 - kubilay

21-05-13 banq

作为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映像被推送到相应的注册表。

如果您仍在跟上现状,那么著名的“集成测试”步骤就来了。

更详细点击标题见原文

猜你喜欢