在非 JVM 环境下使用 Artifactory 中的 Stub 进行 Provider 契约测试

在此流程中，我们假设：

  • API 生产者和 API 消费者是非 JVM 应用。

  • 契约定义以 YAML 格式编写。

  • Stub 存储使用 Artifactory 或 Nexus。

  • 使用 Spring Cloud Contract Docker (SCC Docker) 和 Spring Cloud Contract Stub Runner Docker (SCC Stub Runner Docker) 镜像。

你可以在此处阅读更多关于如何将 Spring Cloud Contract 与 Docker 结合使用的信息。

此处有一篇关于如何在多语言世界中使用 Spring Cloud Contract 的博客文章。

此处有一个 NodeJS 应用示例，该应用同时使用 Spring Cloud Contract 作为生产者和消费者。

生产者流程

从高层次来看，生产者需要

  1. 编写契约定义（例如，使用 YAML）。

  2. 配置构建工具以

    1. 在给定端口上启动带有模拟服务的应用。

      如果无法进行模拟，可以设置基础设施并以有状态的方式定义测试。

    2. 运行 Spring Cloud Contract Docker 镜像，并将正在运行的应用的端口作为环境变量传递。SCC Docker 镜像将

      • 从附加的卷中生成测试。

      • 针对正在运行的应用运行测试。

测试完成后，Stub 会被上传到 Stub 存储位置（例如 Artifactory 或 Git）。

下面的 UML 图展示了生产者流程

flows-provider-non-jvm-producer

消费者流程

从高层次来看，消费者需要

  1. 配置构建工具以

    • 启动 Spring Cloud Contract Stub Runner Docker 镜像并启动 Stub。

      环境变量用于配置

    • 要获取的 Stub。

    • 仓库的位置。

      请注意

    • 要使用本地存储，也可以将其作为卷附加。

    • Stub 运行的端口需要暴露出来。

  2. 针对正在运行的 Stub 运行应用测试。

下面的 UML 图展示了消费者流程

flows-provider-non-jvm-consumer