微服务的测试策略( 二 ) _微服务

我们可以使用测试替身独立运行单元测试。我们也可以让要测试的代码调用其他微服务，这就是我们正在讨论的社交测试。如你所见，可信度与稳定性之间的平衡将贯穿本文始终。模拟可以加快测试速度，降低不确定性，但模拟越多，测试结果的可信度就越低。虽然也有缺点，但社交测试更实用。因此，你要在这两种类型的测试之间做好权衡取舍。
如果你想实际看下独立测试和社交测试的例子，可以读一下 Dylan Watson 在 dev.to 上发表的那篇不错的博文。
微服务的契约测试
当两个服务通过接口耦合时，契约就形成了。契约详细列出了所有可能的输入、输出及其数据结构和副作用。服务的消费者和生产者必须遵守契约描述的规则才能进行通信。
契约测试可以保证微服务遵守契约。它们不会全面测试服务的行为；它们只确保输入和输出具备期望的特性，服务执行时间和性能都在可接受的范围内。
契约测试可以由生产者运行，也可以由消费者运行，还可以两者都运行，这取决于服务之间的关系。

消费者端契约测试由下游团队编写并执行。测试时，微服务连接到生产者服务的模拟版本，检查它是否可以消费其 API 。
生产者端契约测试在上游服务中运行。这类测试会模拟客户端可以发起的各种请求，验证生产者是否符合契约。生产者端测试让开发人员可以知道他们什么时候会破坏消费者兼容性。

文章插图
契约测试可以在上游或下游运行。生产者端测试可以检查服务变更是否会给依赖它的服务造成破坏。消费者端测试使用上游生产者的模拟版本（并非真正的生产者服务）来运行消费者端组件，验证消费者是否可以发起请求，并消费生产者提供的期望响应。我们可以使用类似 wiremock 这样的工具来再现 HTTP 请求。如果两端都通过了契约测试，那么生产者和消费者就是兼容的，应该能够通信。持续集成时应该总是运行契约测试，以便在部署前发现不兼容的情况。
你可以在 Pact 的 5 分钟入门指南里在线试用契约测试。Pact 是一个基于 HTTP 的测试工具，可以编写和运行基于消费者或是生产者的契约测试。
微服务的集成测试
微服务的集成测试方式与其他架构略有不同，其目标是通过微服务交互来识别接口缺陷。与契约测试总有一端是模拟的不同，集成测试使用真实服务。
集成测试不关注服务的行为或业务逻辑。集成测试是为了确保微服务可以与其他微服务以及自己的数据库交互。我们希望通过集成测试来发现类似 HTTP 头缺失、请求 / 响应对不匹配这样的问题。因此，集成测试通常在接口层实现。

文章插图
使用集成测试来检查微服务是否可以与其他服务、数据库和第三方端点通信。建议读下 Vitaly Baum 关于微服务存根的博文，看下实际的集成代码测试。
微服务的组件测试
组件是一个较大的系统中可以完成一项职责的一个微服务或一套微服务。
组件测试是验收测试的一种，使用模拟资源或 mocking 来替换服务，孤立地检查组件的行为。
组件测试比集成测试更全面，它们既会测试快乐路径，也会测试不快乐路径——例如，测试组件如何响应模拟网络中断或恶意请求。我们想知道组件是否满足其消费者的需求，很像我们在验收测试或端到端测试中所做的那样。