从士兵到软件匠人的侃侃而谈

0%

契约测试拨乱反正:最简介绍

一段时间以来研究和实践契约测试,发现如过去大家对于单元测试、集成测试、端到端测试等等测试理解不一致一样,绝大多数情况下都把契约测试理解或应用错了。

为了统一认知,写了个简介,以求被拍砖和拍人。

目的(解决的问题)

契约测试是一种以自动化测试作为技术手段,解决团队间因存在明显沟通边界,由沟通不畅和代码变更而造成的系统间接口不匹配问题的最佳实践。

原理

https://martinfowler.com/articles/practical-test-pyramid.html

通过测试驱动生成服务间的契约文档,利用该契约文档和Mock Server(银行业常称之为“挡板”)分别对契约的消费者和提供者进行自动化测试,以确保双方能够按照契约实现满足规格要求的接口,并利用持续集成流水线实现对双方变更影响的快速反馈。

原则

  • 快速反馈
    • 契约测试应当聚焦对于接口规则的验证,能够易于编写,快速运行,最简验证。所以通常采用测试替身(Test Double)来代替集成组件加快运行速度(速度与单元测试相当)。
  • 测试运行时使消费者与提供者解耦(分别运行测试)
    • 对于接口的功能验证,应当由接口集成测试来保证。
    • 对于系统间的协作验证,应当由系统间集成测试,或端到端测试来保证。
  • 消费者驱动设计优于提供者驱动设计
    • 符合需求拉动和简单设计思想,减少冗余设计。

适用场景 / 条件

  1. 契约测试属于进阶自动化测试实践,团队需具备基本的自动化测试和持续集成实践能力,并了解微服务基本知识和概念。
  2. 系统间采用松耦合的通讯和开发方式,例如HTTP+JSON。而非紧耦合的通讯和开发方式,例如共享接口文件的RPC类框架。
  3. A团队与B团队间存在明显的沟通边界,但二者均可控(可采用统一实践并坚持)。
  4. 提供者提供的接口被多个消费者消费,需要快速反馈代码变更所造成的影响。

前置知识与能力

  • 自动化测试基础
    • 单元测试
    • 集成测试
    • 端到端测试
  • 测试替身
  • 简单设计(增量式设计)/ 测试驱动开发
  • API测试方法
  • 版本控制
  • 持续集成 / 持续交付
  • 微服务

可用工具

  • Pact(推荐)
    • 消费者驱动
    • Pact Specification 契约规范 + 多技术栈实现
    • 基于JSON的契约文件
    • 支持HTTP+JSON的接口实现 / 消息队列
  • Spring Cloud Contract
    • 提供者驱动 / 消费者驱动
    • JVM + Spring 技术栈,可与Pact Broker集成
    • 基于JAR的契约文件
    • 支持HTTP+JSON的接口实现 / 消息队列

欢迎关注我的微信公众号

微信搜索:枪炮与代码,或者搜索公众号ID:guns_n_code

枪炮与玫瑰