API 使用空手道测试容器化微服务
API Testing containerized microservices with Karate
我正在尝试利用空手道 (https://github.com/intuit/karate) 作为整体测试策略的关键组成部分来测试容器化的、基于云的微服务。假设被测微服务和空手道都有自己的容器，流程如下：
- 为本地部署获取每个容器
- 构建（通过 gradle）空手道容器中的组件（假设我们的模拟需要 Java 类）
- 部署（通过 gradle）模拟并在独立模式下获取它们 运行ning
- 将有关模拟的信息注入到微服务的 YAML 中
- 在本地构建和部署微服务
- 运行 通过 CLI 进行空手道测试（传递有关模拟 and/or 环境的信息）
我的第一个问题是这是好主意 (TM) 还是坏主意 (TM)。从表面上看，它似乎既合理又可以实现，但我想知道我是否正在尝试以一种从未打算使用的方式使用空手道。我考虑过将所有空手道内容（包括模拟服务器）保留在测试本身中的想法，但随后步骤 #3-5 必须将模拟信息注入微服务，然后 运行 命令获取微服务在测试套件中构建和部署，这在我看来是一个坏主意（TM）。最好将此作为 Jenkins 工作管道的一部分来执行，对吗？
我的第二个问题是如何最好地导出模拟、文件和 Java 依赖项以供外部使用（以支持步骤 2-3），例如这里是文件结构：
.
+-- build.gradle
+-- src
| +-- main
| +-- java
| +-- JWTSigner
| +-- PEMHelper
| +-- resources
| +-- private-key.pem
| +-- public-key.pem
+-- test
| +-- main
| +-- java
| +-- api
| +-- cats
| +-- cats.feature
| +-- dogs
| +-- dogs.feature
| +-- AllTestsRunner.java
| +-- mocks
| +-- mock-auth.feature
| +-- templates
| +-- public-key.json
| +-- resources
| +-- lolcats.pdf
| +-- loldawg.jpg
所以在这里，mock-auth.feature 需要 src/main 和 src/test/templates 中的内容。我已经能够使用 gradle 任务并使用独立的空手道 JAR 将所需的内容复制到主目录的子目录中，以便可以启动模拟，但我想知道是否有更好的方法。 ..
欢迎任何反馈，但如果是否定的，请提出一个可供我尝试的替代方案。谢谢。
第二个问题的答案在这里：
在我看来，没有 Right Way™ 来协调您的模拟和被测应用程序。你提出的方法会起作用，我会做的是在 Docker 中使用 --network 选项，例如如果网络被称为 mocks 并且您必须决定并可能公开端口号，例如8080，你把第二个容器中的URL-s设置为http://mocks:8080
您可以从 Karate 的分布式测试指南的此页面获得一些想法：https://github.com/intuit/karate/wiki/Distributed-Testing
请注意，空手道模拟旨在仅需要 JRE 和“fatjar”。这可以简化事情，例如您甚至可能不需要“Dockerize”东西，只需在 PATH 上设置 java 并指向您的 *.feature 文件即可。即使您使用 Java 代码，您也可以 或者您可以使用 maven-shade.
自己构建一个“fatjar”
如您所说，移动部件最少的选项可能是在同一个 Java 项目中建立模拟。优点是：
- 您可以动态选择一个端口并将其传递给主应用程序配置
- 启动和停止以及协调 2 个进程更容易（Java 代码）
- 自动处理 CLASSPATH
- 如果您有雄心壮志并在未来尝试代码覆盖，会更容易
进一步阅读：
我正在尝试利用空手道 (https://github.com/intuit/karate) 作为整体测试策略的关键组成部分来测试容器化的、基于云的微服务。假设被测微服务和空手道都有自己的容器，流程如下：
- 为本地部署获取每个容器
- 构建（通过 gradle）空手道容器中的组件（假设我们的模拟需要 Java 类）
- 部署（通过 gradle）模拟并在独立模式下获取它们 运行ning
- 将有关模拟的信息注入到微服务的 YAML 中
- 在本地构建和部署微服务
- 运行 通过 CLI 进行空手道测试（传递有关模拟 and/or 环境的信息）
我的第一个问题是这是好主意 (TM) 还是坏主意 (TM)。从表面上看，它似乎既合理又可以实现，但我想知道我是否正在尝试以一种从未打算使用的方式使用空手道。我考虑过将所有空手道内容（包括模拟服务器）保留在测试本身中的想法，但随后步骤 #3-5 必须将模拟信息注入微服务，然后 运行 命令获取微服务在测试套件中构建和部署，这在我看来是一个坏主意（TM）。最好将此作为 Jenkins 工作管道的一部分来执行，对吗？
我的第二个问题是如何最好地导出模拟、文件和 Java 依赖项以供外部使用（以支持步骤 2-3），例如这里是文件结构：
.
+-- build.gradle
+-- src
| +-- main
| +-- java
| +-- JWTSigner
| +-- PEMHelper
| +-- resources
| +-- private-key.pem
| +-- public-key.pem
+-- test
| +-- main
| +-- java
| +-- api
| +-- cats
| +-- cats.feature
| +-- dogs
| +-- dogs.feature
| +-- AllTestsRunner.java
| +-- mocks
| +-- mock-auth.feature
| +-- templates
| +-- public-key.json
| +-- resources
| +-- lolcats.pdf
| +-- loldawg.jpg
所以在这里，mock-auth.feature 需要 src/main 和 src/test/templates 中的内容。我已经能够使用 gradle 任务并使用独立的空手道 JAR 将所需的内容复制到主目录的子目录中，以便可以启动模拟，但我想知道是否有更好的方法。 ..
欢迎任何反馈，但如果是否定的，请提出一个可供我尝试的替代方案。谢谢。
第二个问题的答案在这里：
在我看来，没有 Right Way™ 来协调您的模拟和被测应用程序。你提出的方法会起作用，我会做的是在 Docker 中使用 --network 选项，例如如果网络被称为 mocks 并且您必须决定并可能公开端口号，例如8080，你把第二个容器中的URL-s设置为http://mocks:8080
您可以从 Karate 的分布式测试指南的此页面获得一些想法：https://github.com/intuit/karate/wiki/Distributed-Testing
请注意，空手道模拟旨在仅需要 JRE 和“fatjar”。这可以简化事情，例如您甚至可能不需要“Dockerize”东西，只需在 PATH 上设置 java 并指向您的 *.feature 文件即可。即使您使用 Java 代码，您也可以 maven-shade.
如您所说，移动部件最少的选项可能是在同一个 Java 项目中建立模拟。优点是：
- 您可以动态选择一个端口并将其传递给主应用程序配置
- 启动和停止以及协调 2 个进程更容易（Java 代码）
- 自动处理 CLASSPATH
- 如果您有雄心壮志并在未来尝试代码覆盖，会更容易
进一步阅读：