测试金字塔

简介

在许多项目中，自动化测试是一个模糊不清的领域。每个人只是按照维基文档中某条陈旧规则的要求随意编写测试，但没有人能清楚回答关于团队测试策略的具体问题。

本章将为六边形架构提供一种测试策略。针对架构中的每个元素，我们将讨论应采用何种类型的测试来覆盖。

让我们从 #key# 测试金字塔 #key# 的角度开始探讨测试。测试金字塔的概念最早可追溯到 Mike Cohn 于 2009 年出版的《Succeeding with Agile》一书。如下图所示，它是一种帮助我们判断应该编写多少测试以及测试类型比例的隐喻。

测试金字塔

其核心思想是：我们应该尽可能多地覆盖那些构建成本低、易于维护、运行快速且稳定的细粒度测试。这类测试即为单元测试，用于验证单个“单元”（通常是一个类）是否按预期工作。

一旦测试涉及多个单元，跨越单元边界、架构边界甚至系统边界，它们往往会变得更难构建、运行更慢，并且更加脆弱（容易因配置错误而非功能缺陷导致失败）。测试金字塔告诉我们，测试越昂贵，就越不应追求高覆盖率，否则我们将花费过多时间在测试开发上，而不是实现新功能。

根据不同上下文，测试金字塔常以不同层次呈现。下面我们来看本课程为讨论六边形架构测试所采用的分层方式。需要注意的是，“单元测试”、“集成测试”和“系统测试”的定义会因上下文而异，其含义可能在不同项目之间有所不同。以下是本章中对这些术语的具体解释。

单元测试

单元测试位于金字塔的底层。一个单元测试通常只实例化一个类，并通过其接口验证其功能是否正确。如果被测类依赖其他类，则这些依赖不会实际实例化，而是用模拟对象（mock）替代，仅模拟出测试所需的行为。

集成测试

集成测试构成金字塔的中间层。这类测试会实例化一组相互协作的多个单元，通过某个入口类的接口传入数据，验证整个协作网络是否按预期工作。在我们的理解中，集成测试会跨越两个层级之间的边界，因此对象网络并不完整，或在某些环节需要依赖模拟对象。

系统测试

系统测试会启动构成应用程序的完整对象网络，验证某个特定用例能否在整个应用各层中按预期正常运行。

在系统测试之上，可能还存在端到端测试层，包含应用的 #key# UI（用户界面） #key#。但本书仅讨论后端架构，因此不涉及端到端测试。