与我一起学习微服务架构设计模式9—测试策略(上)

微服务架构中的测试策略概述

常见问题：

将代码扔给QA团队，手动测试，效率很低，在交付流程中才进行测试为时已晚。

使用微服务的一个关键动机是提高可测试性，微服务架构的复杂性要求编写自动化测试，以缩短交付(代码投入生产环境)周期。

什么是测试

测试的目的是验证被测系统的行为。

测试用例是用于特定目标的一组测试输入、执行条件和预期结果，一组相关的测试用例集构成一个测试套件。

编写自动化测试

每个自动化测试都是通过测试类中一个测试方法实现。测试包括四个阶段：设置——初始化测试环境，这是运行测试的基础；执行——调用被测系统；验证——验证测试的结果；清理——清理测试环境。

使用模拟和桩进行测试

被测系统在运行时常会依赖另一些系统，依赖的麻烦在于它们可能把测试复杂化，减慢测试速度。

解决方案使用测试替身，该对象负责模拟依赖项的行为。

测试替身分为stub(代替依赖项向被测系统发送调用的返回值)，mock(用来验证被测系统是否正确调用来依赖项，也扮演stub的角色)

Mockito：流行的java模拟对象框架

测试的不同类型

根据范围分类：

• 单元测试：测试服务的一小部分，例如类
• 集成测试：验证服务是否可以与基础设施服务或其他服务进行交互
• 组件测试：单个服务的验收测试
• 端到端测试：整个应用程序的测试

测试是开发不可或缺的一部分：编译时单元测试

根据测试象限分类：

使用测试金字塔指导测试工作

微服务架构中的测试挑战

进程间通信是微服务架构的核心，开发人员必须编写测试，以验证其服务是否仍旧能与其依赖关系和客户端进行正常交互

端到端测试复杂耗时。

消费者驱动的契约测试

开发消费者服务的团队负责编写契约测试套件。并将其提交到提供者的测试套件代码库。这些套件由服务方的部署流水线执行，观察测试是否失败。

通常使用样例测试。

使用Spring Cloud的契约测试服务

Spring Cloud Contract是消费者契约测试框架。

Groovy是提供者代码库的一部分。每个消费者团队编写契约，描述如何与提供者交互，并将代码提交给提供者团队。提供者使用Spring Cloud Contract生成测试类，使用契约的请求调用提供者验证返回与契约响应是否匹配，然后将契约打包为JAR发布到Maven库，消息者端测试从存储库下载Jar，契约用于配置桩。

针对消息传递API的消费者契约测试

Spring Cloud Contract也支持基于消息传递方式交互的服务的测试。对提供者测试时，提供者程序触发这个事件，验证它是否与契约中的事件匹配。消费者测试则会验证消费者是否可以处理该事件。

部署流水线

它由一系列阶段组成。提交前测试执行单元测试，由开发人员在提交代码之前运行。其余阶段(提交测试、集成测试、组件测试、部署)由自动化工具执行，如Jenkins CI服务器。

为服务编写单元测试

两种类型单元测试：

独立型单元测试： 使用针对类的依赖性的模拟对象隔离测试类，常用于领域服务(Service),控制器类、入站和出站消息网关的测试。

协作型单元测试： 测试一个类及其依赖项，常用于实体、值对象、Sagas的测试

为实体、值对象编写单元测试

为Saga编写单元测试

你需要为正常执行的场景编写单元测试，还必须为Saga回滚的各种场景编写测试。一种方法是编写使用真实数据库和消息代理以及桩服务的测试，以此模拟各种Saga参与方，但这样测试缓慢，更有效的方法是编写模拟与数据库和消息代理交互的类的测试，这样可以专注于Saga的核心职责。

为领域服务编写单元测试

三个阶段：

1. 配置服务依赖项的模拟对象
2. 调用服务方法
3. 验证服务方法返回的值是否正确，以及是否已正确调用依赖项

为控制器编写单元测试

如Spring Mock Mvc这类框架使你能够测试HTTP请求路由以及Java对象与JSON之间的转换，而无须进行真正的网络调用。

为事件和消息处理程序编写单元测试

每个测试实例都是消息适配器，向消息通道发送消息，并验证是否正确调用了服务模拟。而消息传递的基础设施是基于桩的，因此不涉及消息代理。测试可以使用Eventuate Tram Mock Messaging框架。

单元测试不会验证服务是否与其他服务正确交互，为了验证服务是否正确地与其他服务交互，必须编写集成测试。

java达人

ID：drjava