微服务架构下组件测试方法及其优势.pdfVIP

本文由简悦SimpRead转码，原文地址

到目前为止，我讲解了微服务架构下的单元测试，它的目的是验证软件代码中的每个单元（方法或类

等）是否符合预期；也讲解了微服务架构下的集成测试，它验证微服务是否可以与外部服务或数据

等基础设施服务进行交互；今天来讲解下保障单个微服务的质量的测试方法——组件测试。

组件测试简介

组件（Component）通常指大型系统中任何封装良好、连贯且可独立替换的中间子系统，在微服务架

构中，一般代表单个微服务，因而组件测试（ComponentTesting）就是对单个服务的测试。

在一个典型的微服务应用程序中，会有许多微服务，且它们之间存在相用关系。因此，要想高效地

对单个微服务进试，需要将其依赖的其他微服务和数据模块进行模拟（mock）。

比如，使用测试替身（TestDouble）工具掉单个微服务依赖的其他微服务和数据，避免测试

过程中受到依赖服务或数据模块的各类影响（如服务不可用、服务、数据库连接断开等）而出

现阻塞测试过程、测试无效等情况。

从某种意义上来说，组件测试的本质上是将一个微服务与其依赖的所有其他服务和数据模块等

开，对该服务进行的功能验收测试。

基于组件测试的特性，它有如下优势：

使用测试替身将被测服务与依赖的服务进行，使得服务链路稳定、环境，这有利于测试过

程的开展；

将测试范围限定为单个服务，因而组件的测试设计和测试执行的速度会快很多；

即使测试过程中发现了问题，问题也更容易复现，这不仅有利于定位问题所在，问题修复后也有利

于进行回归验证。

根据组件测试调用其依赖模块的方式，以及测试替身位于被测在进程的或外部，可以有两种

方式：进程内组件测试和进程外组件测试。

进程内组件测试

进程内组件测试是将测试替身注入所测在的进程中，这样对服务的依赖调用通过方法调用的方式

实现，不再需要使用网络。

进程内组件测试示意图

如图所示，进程内组件测试有如下变化：

引入测试替身，即模拟的HTTP客户端（StubHTTPClient）和模拟的内存型数据模块（In-

MemoryDatastore）。其中，模拟的HTTP客户端用来模拟实际的HTTP客户端（liveHttp

Client），模拟的内存型数据模块用来模拟的外部数据模块（External

Datastore）。

将资源（Resources）拆分成了（PublicResources）和资源（Internal

Resources）。服务的网关（eway）连接了模拟的HTTP客户端，不再连接实际的HTTP

客户端。这是因为进程内组件测试不再需要网络通信，模拟的HTTP客户端需要通过一个接口

进行请求的发送和响应，这需要用到一些库进行API之间的转换，常用的有基于微服务的JVM的

inproctester和基于微服务的.NET的sma。

可见，桩（Stub）代码、数据模拟模块均放在所测微在的进程中，使用常驻内存的桩代码和

模拟代替其依赖性，这就是“进程内（in-process）”的具体表现。通过这种方式，测试可以尽可能接近

对被测服务执行的HTTP请求，而不会产生实际网络交互的额外开销。

这样做的好处是：最度地减少不确定因素，降低测试的复杂度，同时加快执行速度；但是其不足在

于，这需要侵入微服务的源代码，让其能够以“测试模式”启动和运行。这种情况下，需要引入依赖注入

框架（DependencyInjectionFrameworks）帮助我们做到这一点，即根据程序在启动时获得的配置，

使用不同的依赖对象。常见的依赖注入框架有Spring、CastleWindsor、Unity、StructureMap、