测试微服务 VS 测试单体式应用

使用微服务比起使用单体式应用程序结构有许多优点。

但是微服务并不像单体式应用程序一样已经有确定的开发模式。

许多问题尚未解决，我们也还没有看到完善的“微服务方式”的实施标准的出现。

测试也不例外。对于整体来说，有单元测试，组件测试，集成测试。界限清晰，编写测试的方式也很清晰。

但是、对于微服务呢？

假设说，你使用微服务之间的 HTTP(s)和 REST 作为你的通信层。

在一个典型的应用中，一个(微)服务有一系列的依赖关系，可能是其他的(微)服务。

在单元测试中一样，第一个想法是模拟对象测试(mocking)。

但是，有什么好方法对微服务模拟对象测试？

或者我们总是应该使用构造的测试数据运行真实依赖的实例(或fixture),来进行测试？

我们想到了另一种方式。

测试层级

对于原生微服务应用1，我们定义了多个层次的测试。

单元

这就是我们熟悉的单元测试，没有什么不同，并且取决于编程语言。

组件

测试服务，无需外部依赖，使用数据 fixture。

容器

测试服务容器。这包括有控制的引入(mocked)依赖关系并测试容器服务在不同情况下的行为,以及测试暴露的 API。

API 的规格说明和测试端点

如果你认真对待你的诸多微服务的持续集成，你会考虑编写一个 API 的规格说明。

建立一个规格说明允许你建立一个生产者和一个 API 消费者之间的契约。这是维护性和持续集成的关键。我们选择了 OpenAPI(Swagger)来描述我们的微服务。

现在我们已经有了规范，第一个合理的步骤就是将自动 API 测试集成到我们的测试工作流程中。为此，我们选择了一个杰出的工具 Dredd[2]。

用 Dredd 测试 API

Dredd 简单而有效。

你需要提供你的 Swagger(或APIBlueprint)定义以及符合规格说明的 API 的端点。然后，它会针对此端点运行测试，并确保其按照规格说明描述的方式进行。

集成到测试工作流程中

我们使用容器来运行我们的微服务，也运行我们的测试套件。每个级别的测试都是一个目录，其中包含一组针对该级别的测试。

我们来看一下容器级的 API 测试：

在这里，我们针对 API 端点运行 Dredd。

例程启动 Dredd 容器，并使用正在运行的 API 向其提供 spec 和端点的位置。Dredd 提供了 hooks.js 文件，该文件为数据库提供了服务的 fixture。

您可以了解更多关于我们在存储库上创建的 Dredd Docker 镜像的信息[3]，并阅读文档[4]中有关 Dredd 钩子的更多信息。

更多的工作

通过这个流程，我们定义了微服务测试层级并且将 API 端点测试集成在持续集成阶段。还有很多工作要做。例如，为 API 引入版本会很好。

此外，目前我们必须手动编写和更新规格说明，这很快就让人觉得繁琐而无聊。但是，由于我们在微服务中使用了不同的技术，我们也还没有实现全自动化，这些问题也暂时是难以避免的。

但是，这是一个好的开始，并且在我们继续部署服务时给予我们更多的信心。

[1] http://thenewstack.io/start-socks-towards-cloud-native-reference-application/ [2] https://github.com/apiaryio/dredd [3] https://github.com/microservices-demo/microservices-demo/tree/master/openapi [4] https://dredd.readthedocs.io/en/latest/hooks/

编者注: Dredds 是基于 CoffeeScript 的一个开源测试框架,他并不绑定任何语言，而是根据定义好的 API 规格说明，一步步测试 API 能否按照描述返回正确的结果来验证API是否正确实现。

文章翻译自：https://container-solutions.com/testing-microservices-approach-api-testing/ 作者：Aleksandr Guljajev

END