不得不说的微服务测试

在微服务架构下，给我们测试带来了如下挑战：

验证成本高，为了验证多个服务协作后的功能正确与否，需要为每个服务搭建基础设施（包括数据库、缓存等），并执行部署、配置等步骤，以确保服务能正确运行。
结果不稳定，分布式系统，服务之间的通信都是通过网络调用，然而在网络上传送，都会面临网络延时、超时、带宽等因素，容易导致不稳定的测试结果。
反馈周期长，相比单体应用而言，微服务架构下，可独立部署的单元多，因此集成测试的反馈周期比之前会更长，定位问题的时间就会更久。
沟通成本高，微服务常由不同团队开发并维护，当服务频繁进行改动和版本升级的时候，很容易导致不兼容，加大团队之间的沟通成本。

测试金字塔

测试金字塔很好的帮助我们在制定测试策略的时候，区分不同层次测试关注点，同时，一般来说，测试颗粒度越粗，越脆弱，执行的时间越长，维护成本也越高。

不得不说的契约测试

在微服务中，不得不聊聊消费者契约测试，

契约，一种定义在Consumer与Provider之间的交互方式

消费者驱动的契约测试

契约是Consumer和Provider团队之间达成的交互协议，更多的看中的是请求和响应的Payload结构（Schema），由服务消费者构建并生成contract，然后将contact上传到Pact broker or server；对应的服务提供者，需要在Pipeline中，有一个task进行契约的验证，保证契约不会被破坏。

契约测试的好处

测试分层，Consumer和Provider分别测试。
测试前移，为Consumer提供Mock，不需要真实的集成环境，稳定性高。
反馈周期短，单元测试级别，测试运行快，毫米级。
沟通成本底

为服务消费者提供了信心，更为服务提供者提供了更大的价值（通过与不同消费者约定的契约，可以保证服务安全的升级变迁，不会破坏之前已有的功能）

契约测试的应用场景

一个服务需要被多个消费者使用，每个消费者的诉求并不完全一样（一对一的场景，没有太大意义）。
服务消费者与服务提供者由不同的团队开发维护。
服务消费者与服务提供者，一定要对契约达成一致，并一直保持这种约束（如果有一方没有遵守，比如提供者根本不将契约验证集成到流水线中，那么就没有任何意义），契约的不符合预期的变化应当会造成测试的失败。

应该关注

检查Consumer构建的请求是否匹配到了对应的Contract
检查Provider的响应是否满足Consumer的需要

不应该关注

Provider的业务逻辑是否正确
Consumer的处理响应的逻辑

可参考的工具： Pact, Spring Cloud Contract等

不得不说的集成测试

集成测试验证服务或者组件之间的连通性和交互以检查接口缺陷，集成测试旨在通过集成不同的Downstream服务，来覆盖基本的成功和错误的场景，在我们项目中，选用REST Assured作为集成测试工具，使用非常方便:

@RunWith(SpringRunner.class)
@SpringBootTest(webEnvironment = WebEnvironment.RANDOM_PORT)
@AutoConfigureRestDocs
public class UserDocumentationTests {

    @LocalServerPort
    private int port;

    @Autowired
    private RequestSpecification documentationSpec;

    @Test
    public void listUsers() {
        given(this.documentationSpec).filter(document("list-users")).when()
                .port(this.port).get("/").then().assertThat().statusCode(is(200));
    }

}

当downstream服务非常不稳定的时候，我们会通过wiremock作为proxy对请求和响应进行录制，使用wiremock做测试替身，隔离外部调用，避免多服务间的复杂情况（网络，其他团队服务可用性等），并以可重复的方式模拟任何场景（超时，Down机，SSL验证失败，丢失HTTP头，请求响应不匹配等），运行稳定，且反馈周期短。