微服务架构的测试策略

在JUnit5 有了很多新的注解可以帮助我们高效完成单元测试需求

比如我们可以使用 @BeforeAll可以在当前类的所有方法之前前执行方法，

@AfterAll在所有测试方法执行后执行方法，

甚至可以使用@TestMethodOrder注解指定测试方法的执行前后顺序。

点击查看更多注解

如果我们想只是测试一个Controller 而把整个应用程序所有组件都启动起来是不切实际的。

因此，针对单元测试的一个建议是尽可能使用测试替身。

测试替身一般有两种，一种是使用Mock对象，另外一种是Stub对象。

1.2.2.1.1 Mock对象

关于Mock 对象，很多人应该比较熟悉，MockEnvironment,MockMvc,

这里贴一个例子：

class MyWebTests {

    MockMvc mockMvc;

    @BeforeEach
    void setup() {
        this.mockMvc = MockMvcBuilders.standaloneSetup(new AccountController()).build();
    }

    @Test
    void getAccount() throws Exception {
        this.mockMvc.perform(get("/accounts/1")
                .accept(MediaType.APPLICATION_JSON))
            .andExpect(status().isOk())
            .andExpect(content().contentType("application/json"))
            .andExpect(jsonPath("$.name").value("Lee"));
    }
}

更多其他Mock对象框架选择： Mocketito 是一种流行的Java模拟对象框架

更多学习和用法请参考

Spring MVC Test

Spring Boot Test Features

Spring Boot test Auto Configuration

1.2.2.1.2 Stub 对象

另外一种Stub (存根)对象，这个是神马东东呢？

Stub 江湖俗称占坑对象，稍后详解。

为屏蔽客户调用远程主机上的对象，必须提供某种方式来模拟本地对象,这种本地对象称为存根(stub),存根负责接收本地方法调用,并将它们委派给各自的具体实现对象

1.2.2.2 端到端的测试建议

假设我们有一个包含多个微服务的系统，如下图所示：
在这里插入图片描述
如果我们要测试上图中这个应用程序，看看它是否可以与其他服务通信，我们可以执行以下两项操作之一：

部署所有微服务并执行端到端测试。
在单元和集成测试中模拟其他微服务。

这两种方法都有优点，也有很多缺点。

第一种方式：部署所有微服务并执行端到端测试

优点：

模拟生产环境

测试服务之间的真实通信

缺点：

为了测试一个微服务，我们必须部署六个微服务，几个数据库以及其他项目

测试运行的环境被锁定为单个测试套件（在此期间，其他任何人都无法运行测试）

需要很长时间才能运行

反馈在此过程中非常慢

很难调试

第二种方式：在单元和集成测试中模拟其他微服务

优点：

他们提供了非常快速的反馈。

他们没有基础架构要求。

缺点：

服务的实现者创建的存根可能与现实无关。

您可以通过测试并通过失败的生产。

因此最好避免像这样的端到端测试。

那么有没有什么更好的测试方法呢？

答案是肯定的，那就是使用契约测试。

1.2.2.2.1 什么是契约测试？

那么什么是契约测试呢？
在这里插入图片描述

契约测试通常使用样例测试，消费者和提供者之间的交互由一组样例定义，称为契约。

每个契约都包含在一次交互期间交换的样例消息。

契约测试提供了一种新的测试方式 - 基于接口，也就是说每个微服务都提供自己的测试接口以及请求的测试数据，期待的测试结果。

例如，REST API 的契约包含示例HTTP 请求和响应。

1.2.2.2.2 契约测试的设计思想

契约测试的主要设计思想是为我们提供非常快速的反馈，而无需建立整个微服务。如果我们使用stub，则仅需要应用程序直接使用的应用程序。

可以把契约理解成接口，不过这个接口不是传统意义上的接口。它是一段groovy或yaml代码，消费者和生产者在这段代码中约定了request 什么就可以response什么。一方面生产者可以自己去验证是否实现了契约，即真实开发完成后检查能否实现request什么，就返回什么的契约。消费者测试不会真的等生产者启动服务，而是使用框架给生产者根据契约生成一个模拟的stub（mock)文件，它可以提供同样的模拟服务，比如request什么，response什么。
在这里插入图片描述

1.2.2.2.3 如何实现契约测试？

两个比较流行的企业级契约测试框架是Spring Cloud Contract 和支持多种语言的Pact系列框架。

Spring Cloud Contract 官网：https://spring.io/projects/spring-cloud-contract
Pact 官网：https://github.com/pact-foundation

默认情况下，Spring Cloud Contract与Wiremock集成为HTTP服务器Stub（存根）。

这里贴一段示例体会下，更多请移步官方文档参考学习。

package contracts

org.springframework.cloud.contract.spec.Contract.make {
    request { // (1)
        method 'PUT' // (2)
        url '/fraudcheck' // (3)
        body([ // (4)
               "client.id": $(regex('[0-9]{10}')),
               loanAmount : 99999
        ])
        headers { // (5)
            contentType('application/json')
        }
    }
    response { // (6)
        status OK() // (7)
        body([ // (8)
               fraudCheckStatus  : "FRAUD",
               "rejection.reason": "Amount too high"
        ])
        headers { // (9)
            contentType('application/json')
        }
    }
}

1.2.3 部署流水线实现自动化测试

其实很多企业都是手动测试，缺乏自动化测试的原因主要是文化，比如“测试是QA的工作，开发人员的时间不应该花在测试上”,还有一部分原因是一些开发人员并不十分熟悉如何写好测试用例。

但是在微服务架构下最好的实践是集成自动化测试。
在这里插入图片描述
上图所示的部署流水线包括如下阶段：

提交前的测试阶段：执行单元测试，这是由开发人员在提交代码变更之前执行的。

提交测试阶段：编译服务，执行单元测试，并执行静态代码分析。

集成测试框架：执行集成测试

组件测试阶段：执行服务的组件测试。

部署阶段：将服务部署到生产环境中。

当开发人员提交代码更改时，持续集成服务器（比如Jenkins）就会运行提交测试。

处理提交前的测试不是自动化的，其他部分基本上都是自动化测试。

但是值得注意的是，有些情况仍然需要手动操作，比如将项目打包发布到生产环境的时候。

在这种情况下，最好只有测试人员单击一个按钮表明该阶段通过时才会进入下一阶段。

1.3 微服务架构下的测试总结

单体架构下应用开发的测试通常都是在开发完成后执行，而且大多都是手工测试，但是当到了微服务架构这种方式不再适用。

一方面原因在于手动测试效率极地，微服务与微服务之间跨进程的测试，手动测试费时费力。
另一方面等到交付流程时才进行测试时候为时已晚，会延长项目交付日期。

总结建议如下：

自动化测试是快速，安全交付软件的重要基础，由于微服务架构固有的复杂性，必须实现自动化测试。

简单和加快测试的方式是使用测试替身，比如Mock 对象或Spring Cloud Contract.

根据测试金字塔参考应该尽可能减少端到端测试的数量，因为写入耗时，脆弱，且耗时。

1.4 参考资料

Spring Cloud Contract
《微服务架构设计模式》

本篇完～

查看专栏详情

技术宅星云博客专家

发布了194 篇原创文章 · 获赞 262 · 访问量 48万+

他的留言板关注