企业官网建设流程全解析

• 文档
• 教程
• 后端

导读

本文来自开源仓库 nodebestpractices（The Node.js best practices list）中「测试与质量」章节的核心条目，讲解如何在 Node.js 项目中用AAA（Arrange 准备 → Act 执行 → Assert 断言）三段式结构组织单元测试。读完本文，你将理解 AAA 模式的三个阶段分别承担什么职责、如何写出「像读 HTML 一样轻松」的声明式测试用例，以及为什么这种统一结构能显著降低整个测试套件的维护成本。

为什么测试代码必须「死简单」

在真实的 Node.js 项目中，我们的精力早已被生产代码占满——这是测试编写面临的最大挑战：心智空间（headspace）不足。因此，测试代码必须保持极度简单、易于理解。

当我们阅读一个测试用例时，它不应该像在读命令式代码（循环、继承、嵌套逻辑），而应该更像在读 HTML——一种声明式体验：扫一眼就能知道测试在验证什么、场景是什么、预期是什么。AAA 约定正是为了实现这一目标而存在：它让读者的大脑无需额外消耗「CPU」就能解析测试意图。

该条目在 README.md 中的官方 TL;DR 表述为：

TL;DR:用三个清晰分离的段落组织测试：Arrange、Act 与 Assert（AAA）。第一部分包含测试设置（setup），然后是待测单元的执行，最后是断言阶段。遵循这一结构可以保证读者不必花费脑力去理解测试计划。

AAA 模式的三个阶段

AAA 模式与 XUnit 的经典「Setup、Exercise、Verify、Teardown」四阶段测试格式同源，但它用三个 A 更精炼地概括了核心流程：

1. Arrange（准备）

全部设置代码，用于把系统带到测试想要模拟的那个场景。可能包括：

• 实例化待测单元（unit under test）的构造函数
• 向数据库添加测试记录
• 对对象进行 mock / stub（打桩）
• 以及其他任何准备性代码

2. Act（执行）

执行待测单元。通常是1 行代码——调用被测函数、触发被测行为。

3. Assert（断言）

确认得到的值满足预期。通常也是1 行代码——用断言库检查结果是否符合期望。

核心原则：Act 和 Assert 各自尽量保持单行，让测试的关键动作一目了然。

代码示例：遵循 AAA 模式组织的测试

以仓库文档（sections/testingandquality/aaa.md）中的经典「客户分类器」示例为准——该示例同时被收录进仓库的配套图片 6-parts-in-test.jpg 中，作为规范测试用例的教学范例：

describe.skip('Customer classifier', () => { test('When customer spent more than 500$, should be classified as premium', () => { //Arrange const customerToClassify = {spent:505, joined: new Date(), id:1} const DBStub = sinon.stub(dataAccess, 'getCustomer') .reply({id:1, classification: 'regular'}); //Act const receivedClassification = customerClassifier.classifyCustomer(customerToClassify); //Assert expect(receivedClassification).toMatch('premium'); }); });

分析这段代码，你能清晰看到三层结构：

这里使用的工具与库均为 Node.js 测试生态中的主流选择：describe/test来自 Jest 或 Mocha 系测试框架，sinon.stub是经典的测试打桩库，expect是断言 API。模式本身与具体框架无关——无论你使用 Jest、Mocha 还是 Vitest，都可以套用同样的三段结构。

反模式：没有分离的「一坨」测试

对比下面的反模式示例——它包含了与上面完全相同的代码，但缺少任何分段注释和结构划分：

test('Should be classified as premium', () => { const customerToClassify = {spent:505, joined: new Date(), id:1} const DBStub = sinon.stub(dataAccess, 'getCustomer') .reply({id:1, classification: 'regular'}); const receivedClassification = customerClassifier.classifyCustomer(customerToClassify); expect(receivedClassification).toMatch('premium'); });

两者的断言结果完全一致，但阅读体验天差地别：

• 没有//Arrange、//Act、//Assert的视觉分界，读者必须通读每一行才能推断「哪些是准备、哪些是执行、哪些是校验」；
• 当测试较长时，混在一起的设置代码会严重干扰对核心行为的判断；
• 测试失败时，定位失败原因的成本更高——因为读者无法快速锁定断言阶段。

这正是文档中所强调的：没有分离的测试更难解读（harder to interpret）。AAA 的价值不在于改变断言逻辑，而在于用一致的视觉结构降低读者的认知负担。

每个测试应包含的 6 个组成部分

AAA 模式并不是孤立的。在仓库配套的规范图示 6-parts-in-test.jpg（源自 Yoni Goldberg 的博客《30 Node.js testing best practices》）中，一份合格的测试用例被进一步拆解为6 个组成部分，而 AAA 正是其中 3 个阶段的核心支撑：

AAA 模式与测试用例 6 要素结构图

图中展示的 6 个要素为：

1. 被测试的单元（Unit under test）：例如describe块标记的Customer classifier；
2. 测试场景（Scenario）：用例名称描述的条件，例如「客户消费超过 500$」；
3. 预期结果（Expectation）：测试要达成的目标，例如「应被归类为 premium」；
4. Arrange：初始化测试数据（如客户对象、DB stub）；
5. Act：执行被测业务逻辑（如classifyCustomer）；
6. Assert：校验执行结果（如expect断言）。

换句话说：前 3 个要素解决「测试在测什么」的语义问题（场景 + 预期），后 3 个要素（即 AAA）解决「测试怎么写」的结构问题。两者结合，才能产出既语义清晰又结构规范的测试。

与之配套的还有仓库中的姊妹条目 Include 3 parts in each test name——它要求测试名称也应包含 3 部分：测什么（What）、什么场景下（Under what circumstances）、期望结果是什么（What is the expected result）。例如When no price is specified, then the product status is pending approval。AAA 关注测试内部结构，3 部分命名法关注测试对外语义，二者共同构成测试可读性的完整方案。

为什么快速识别测试意图如此重要

文档引用了经典测试模式著作《XUnit Patterns》中的观点：

对于测试读者来说，重要的是能够快速确定测试在验证什么行为。当被测系统（SUT）的各种行为被依次调用——一些用于搭建 SUT 的测试前状态（fixture），另一些用于执行 SUT，还有一些用于验证 SUT 的测试后状态——这种混合会让人非常困惑。清晰地区分这些阶段，能让测试的意图变得容易得多。

这句话点出了 AAA 的深层动机：在一个测试用例中，代码承担着三种截然不同的职责（搭建环境、驱动被测系统、校验结果）。如果这三种职责纠缠在一起，读者就无法快速回答「这个测试到底在验证什么」。AAA 用强制性的三段划分，把这种认知成本降到最低。

从仓库的工程实践看，这一理念也与 Test the five potential outcomes 一脉相承——该条目建议测试覆盖流程的五类产出（响应、新状态、外部调用、消息队列、可观测性），而无论验证哪类产出，清晰的 Arrange-Act-Assert 结构都是让验证过程可读、可维护的前提。

实践建议：从 Assert 先写起

关于 AAA 的落地顺序，文档还引用了 Bill Wake 首次提出并命名该模式的经典文章《Arrange, Act, Assert》中的一个实用技巧：

你可能会认为 Arrange 理所当然应该先写，因为它排在第一位。但在系统性地梳理对象行为时，我也可能先写 Act 这一行。

而从 Jim Newkirk 那里学到的更有用的技巧是：先写 Assert 是一个很好的起点。当你意识到一个想测试的新行为时，Assert First 让你从「假设它成功了，我怎样才能看出来？」这个问题开始。Assert 就位后，你就可以「框架先行」（Frame First），借助 IDE 来「填空」。

也就是说，编写测试的推荐顺序是：先写断言（Assert），再写执行（Act），最后补上准备（Arrange）。这种「以终为始」的写法能帮助你更早澄清行为的验收标准，避免在设置代码上过度投入。

统一结构：降低整个测试套件的维护成本

最后，文档引用《Unit Testing: Principles, Practices, and Patterns》一书总结了 AAA 模式最大的长期收益：

3A 模式简单，并为套件中的所有测试提供了统一的结构。这种统一性正是它最大的优势之一：一旦你习惯了这种模式，就能更轻松地阅读和理解测试。而这反过来又降低了整个测试套件的维护成本。

在大型 Node.js 项目中，测试代码的规模往往数倍于业务代码。统一的 AAA 结构意味着：

• 任何开发者接手任何测试文件，都能按同样的心智模型快速定位准备、执行、断言三段；
• 代码评审时，评审者无需逐行解读即可判断测试是否覆盖了关键场景；
• 长期维护时，修改被测逻辑后能更快找到需要同步更新的断言。

总结

AAA（Arrange-Act-Assert）是 Node.js 项目中最基础也最重要的测试组织规范：

• Arrange负责把所有设置代码集中到测试开头；
• Act用一行代码执行被测单元；
• Assert用一行断言校验结果。

配合「先写 Assert」的编写顺序、测试名称的 3 部分语义法（见 3-parts-in-name.md）以及 6 要素测试结构（见 6-parts-in-test.jpg），你可以把测试从「需要通读的代码」变成「一眼可读的声明式文档」。本文全部示例与引文均可追溯至仓库文档 sections/testingandquality/aaa.md，完整的测试与质量实践目录见 README.md 第 4 节。

• 文档
• 教程
• 后端