测试 Spring Cloud 项目

工程 | Marcin Grzejszczak | 2016年1月4日 | ...

欢迎阅读我作为 Spring Cloud 团队成员的第一篇博客文章 :)

我加入团队已经一个月了，值得分享一下这段时间发生的一些有趣的事情。

如果你读过我在我的 Too Much Coding 博客上发表的任何文章，你就会知道我痴迷于两件事——测试和微服务。由于我现在所做的一切都与微服务相关，所以今天的文章将讨论测试。

Spring Cloud 项目

当我加入 Spring Cloud 团队时，我快速浏览了 Github，结果发现我们有很多项目需要管理，包括

Spring Cloud Netflix（包括 Eureka 服务发现和注册中心、Hystrix、Feign 和 Ribbon 支持）
Spring Cloud Zookeeper
Spring Cloud Consul
Spring Cloud Sleuth

所有这些都依赖于 Spring 和 Spring Boot。当然，每个项目都有自己的版本。这是很多相互依赖的项目，不是吗？

如何测试依赖项？

我想确保如果有人更改 Spring 核心或 Spring Boot 中的内容，我们能立即知道我们的库是否仍然可以运行。当然，我们可以在 CI 工具上创建重复构建，但即使集成测试通过了，仍然有可能存在类路径和 JAR 打包问题。

我建议编写一些端到端测试……

现在，任何读过我关于微服务部署的文章的人都会说我疯了，因为在那种特定情况下我完全反对端到端测试。那么，发生了什么变化呢？

为什么端到端测试是个好主意？

二元方法——有效还是无效？

对于如此大量的项目，在目前这个时间点，我不想遍历所有 Github 仓库，检查它们的测试并确保一切正常。我想要一个黑盒解决方案，它能告诉我应用程序是否正常工作。

跨项目测试

创建的应用程序将使用我们的许多不同项目。端到端测试将捕获这些项目中的任何重大更改。

应用程序打包

我有几次检查了测试，运行了 `./gradlew bootRun`，一切似乎都正常工作。除了 `java -jar ...` 不起作用，因为打包坏了。我也想测试这一点。

使用示例

我想创建几个项目来展示 Spring Cloud 的使用方法。我想站在一个新的 Spring Cloud 用户的角度，有一个地方可以快速设置整个应用程序和基础设施的世界，并四处点击以查看反应。

啤酒厂项目

由于我已经做了一些关于微服务的演讲，我已经准备好了示例代码（感谢 Szimano，他是初始解决方案的共同作者）。我已经调整、弯曲和修改了它，于是就有了啤酒厂。

总体概述

总体思路是，有三个应用程序相互通信

展示服务
酿造服务
Zuul 服务

**展示服务**是用户的 UI，用户可以在其中订购啤酒酿造所需的原料。它的后端还包含酿造过程的状态。

这是该服务的 UI

Diagram

**酿造服务**是一个大型应用程序，负责多种功能。最初它被拆分成几个微服务，但为了简单起见，我们决定减少可部署单元的数量。回到功能上，这些功能包括

收集原料
啤酒成熟
将啤酒装瓶
报告（监听系统中的事件并将它们放入内存数据存储中）

**Zuul 服务**只是一个 Zuul 路由器。

这个系统的理念是，所有组件都使用服务发现或 Spring Cloud Stream 来相互通信。

查看自述文件，了解有关项目结构的更多信息。

可重用性

我想实现的是可重用性。为了使用 Spring Cloud Sleuth 和 Spring Cloud Zookeeper 作为服务注册中心进行测试，我不想更改任何代码。只想使用不同的参数运行测试。

我们使用 Spring Cloud 抽象来做到这一点，因此如果我们从 Eureka 切换到 Consul，则根本不需要更改任何代码，应用程序仍然能够通信（这是一个 JAR 和配置更改的问题）。我也想测试这一点。

约定

啤酒厂应用程序中有一堆约定。主要约定是，`docker-compose` yml 文件具有特定后缀，对应于测试的功能。

docker-compose-CONSUL.yml
docker-compose-EUREKA.yml
docker-compose-SLEUTH_STREAM.yml
docker-compose-SLEUTH.yml
docker-compose-ZOOKEEPER.yml

每个 `docker-compose` 文件都知道如何运行整个应用程序和基础设施世界来测试给定的功能。

如何运行应用程序？

首先，您必须使用 Gradle 构建应用程序及其 Dockerfile。您还必须传递WHAT_TO_TEST系统参数。根据该参数选择应用程序的类路径。例如，对于SLEUTH。

./gradlew clean build -DWHAT_TO_TEST=SLEUTH --parallel

完成后，只需运行上述 bash 脚本即可运行所需的应用程序。

docker-compose -f docker-compose-SLEUTH.yml up -d

注意：有时启动顺序很重要，因此如果您想手动执行操作，请检查给定功能的相应 bash 文件，例如docker-compose-SLEUTH.sh。

通常，最好与运行测试一起启动应用程序。怎么做？只有一行代码。请查看下一节以获取更多信息。

如何运行测试？

如文档中所述

最简单的方法是

Create a symbolic link somewhere on your drive to the acceptance-tests/scripts/runDockerAcceptanceTests.sh file.
You can execute that script with such options
    -t what do you want to test (SLEUTH, ZOOKEEPER etc.)
    -v in which version of the BOM (defaults to Brixton.BUILD-SNAPSHOT)
    -h where is your docker host? (defaults to '127.0.0.1' - provide your docker-machine host here)
    -r is brewery repo already in place and needs to be reset? (defaults to not resetting of repo)

运行脚本后，将克隆啤酒厂应用程序，使用正确的库版本构建，并执行正确的测试。

因此，如果您想运行测试，只需复制粘贴下面的代码。

git clone https://github.com/spring-cloud-samples/brewery.git
ln -s brewery/acceptance-tests/scripts/runDockerAcceptanceTests.sh  .
bash runDockerAcceptanceTests.sh -t SLEUTH

如果您是 Mac 用户，最后一行应类似于此（例如，192.168.50.60 为您的 docker-machine IP）

bash runDockerAcceptanceTests.sh -t SLEUTH -h 192.168.50.60

如果您已下载依赖项，则所有构建、下载和测试运行最多需要 5 分钟。

如果您已设置所有应用程序，则可以手动运行验收测试。请查看下一节以获取有关此方面的更多信息。

测试是什么样的以及如何运行它们？

验收测试位于啤酒厂的acceptance-tests Gradle 模块下。您可以通过以下方式运行它们：

从 IDE（记住传递正确的-DWHAT_TO_TEST系统参数）
从 Gradle（SLEUTH 示例）./gradlew :acceptance-tests:acceptanceTests -DWHAT_TO_TEST=SLEUTH）
- 如果您在 Mac 上运行，则必须额外传递-DLOCAL_URL=192.168.60.50参数，其中192.168.60.50是您的 docker-machine 的 IP。

测试使用 Spock 框架在 Groovy 中编写。如果您从未听说过 Spock，那么现在是您开始在项目中使用它的好时机。查看 Github 代码，其中包含在啤酒厂中使用的 Spock 测试示例。

如果您将 Spock 与 Spock-reports 结合使用，则可以获得非常不错的 BDD 式测试输出。

spock_reports

端到端测试是灵丹妙药吗？

看起来一切都很棒，但实际上并非如此。端到端测试有其优点，但也肯定有很多缺点。这些是：

反馈周期长（您必须等待大约 5 分钟才能查看测试是否通过）
难以调试（您大约有 8 个可能出错的应用程序——您必须检查每个应用程序的日志才能查看发生了什么错误）
网络问题和随机故障（这是最坏的情况，因为它通常是随机的——突然一个数据包丢失了，而 Zipkin 服务器没有收到对测试通过至关重要的跨度……）
测试代码位于被测库之外（幸运的是测试代码不会更改，但最好将与应用程序相关的所有代码放在一个存储库中）

目前的设置适合我们的需求，但实际上我们希望事情进一步改进。这就是为什么我们正在考虑对当前测试方法进行一些改进。

下一步是什么？

目前，端到端测试与 Travis 的构建一起执行。但是……

最终，我们计划仅定期在我们的 CI 服务器上运行这些测试。
我们将把端到端测试的部分内容作为集成测试移到给定的库中，以便更容易调试任何问题。
我们希望扩展我们的测试，以便也在 Cloud Foundry 上执行。

我们的目标是从库的代码库中执行的测试获得更快的反馈。我们还希望我们的集成测试更可靠。

总结

在这篇文章中，您可以看到：

如何酿造啤酒
使用 Docker、Docker Compose、Travis、Bash 脚本和 Gradle 测试开源库的方法
端到端测试的优缺点
Spring Cloud 团队对其库测试的长期计划是什么
敏捷的工作方式（我们有一种测试方法——e2e 测试——但我们知道它的缺点，并且我们正在迭代地计划迁移到更好的解决方案）

更新

[2016年1月15日] 现在执行 e2e 测试容易多了

git clone https://github.com/spring-cloud-samples/brewery.git
cd brewery
bash runAcceptanceTests.sh -t SLEUTH

不再有符号链接（以及更少的 docker-compose）！

如果您想运行测试并在最后终止所有应用程序，只需执行

git clone https://github.com/spring-cloud-samples/brewery.git
cd brewery
bash runAcceptanceTests.sh -t SLEUTH -k

另请查看啤酒厂项目的自述文件以了解任何更改：https://github.com/spring-cloud-samples/brewery

Spring 博客