testing

Testing

概述

写能真正抓住 bug、且不脆弱（改实现不会无端崩）的测试。核心：测试是行为的契约，不是"代码的镜像"——测的是"给它这个输入，该有这个结果"，不是"它内部该这样工作"。好测试让你敢改实现（因为测试守着行为），坏测试让你不敢改（因为一改测试就崩）。

何时使用

• 写完功能，要补测试
• 写测试时纠结测什么、不测什么、要不要 mock
• 现有测试脆弱（改实现就一片红）或 flaky（时过时不过）
• 测试覆盖率挺高但 bug 还是漏

不该用：纯探索/原型（不要求正确，测试是负担）；一次性脚本（跑完即弃）。

与相邻 skill 的衔接：testing 在 task-breakdown 下游、verify-and-fix 上游——task 拆出"做完 X 能验证 Y"，testing 负责把 Y 写成可重复运行的测试，verify-and-fix 负责跑它验证。三者接力：task 定验证目标 → testing 把目标落地成测试 → verify-and-fix 用测试验证完成。

核心内容

先识别被测对象的性质

写测试前先看清"被测的是什么"，策略大不相同——这决定了要不要 mock、用什么工具、放哪个层次：

• 纯函数（无副作用、输入决定输出，如 calculateDiscount）→ 直接输入输出断言，零 mock，单元层。
• 有外部依赖的逻辑（如调 DB/HTTP 的 service）→ mock 掉外部副作用，验证被测逻辑对依赖返回值的真实处理（详见下文 mock 纪律）。
• UI 组件（渲染 + 交互）→ 用组件测试库测渲染输出和用户交互，不测内部 state 细节。
• 模块协作（多个组件配合）→ 集成层，用真实（或内存版）依赖验证组件间契约。

识别性质能避免最常见的错配：给纯函数上 mock、给 UI 组件测 state、把单元能测的逻辑推到端到端。先问"它是什么"，再问"怎么测"。

测行为，不测实现

这是测试设计的第一原则。测"做什么"，不测"怎么做"：

• 测行为（对）：给定输入，断言输出/可观测结果。例：calculateDiscount(100, 'vip') 应返回 80。
• 测实现（错）：断言内部走了哪个分支、调了哪个方法几次。例：断言"内部调用了 multiply 两次"。

为什么测实现糟糕：实现是会变的（重构、换算法、优化），但行为不该变。测实现的测试，每次合理的实现改动都会让它崩——这就是脆弱测试。它逼你改实现时还得改测试，让测试从"保护"变成"负担"。

判别尺子：问自己"如果我把内部实现整个换掉（但行为不变），这个测试还该过吗？" 该过 → 测的是行为（对）；崩了 → 测的是实现（错，改）。

例外：有些"交互契约"本身就是行为——比如"调支付时确实发了请求""保存时确实写库了"。这类"验证发生了正确的外部交互"是测行为，不是测实现。区分点：你关心的是结果（钱扣了/数据存了），还是调用细节（调了 3 次不是 2 次）。前者是行为，后者是过度断言。

测什么：聚焦有判断的逻辑，跳过无价值的

不是每行代码都值得测。测试有价值，是因为代码有逻辑、可能错。按代码性质分：

• 有判断的逻辑（分支、计算、状态转换、边界处理）→ 重点测。这是 bug 高发区。
• 纯数据搬运（getter/setter、直接赋值、简单透传）→ 不值得专门测。测它等于测语言本身。
• 框架/库的代码 → 不测。你不需要测 ORM 的 save 有没有存数据库，那是框架的事。

判断尺子：这段代码如果写错了，测试能抓住吗？写对了，测试有信息量吗？ 两问都否 → 不值得测（如 getter）。把测试预算投到"写错会出事"的地方。

边界和错误路径是重点：happy path 谁都会测，但 bug 大多藏在边界（空值、零、负数、空集合、最大值）和错误路径（异常、超时、依赖失败）。问自己"这个函数在什么输入下会出错？"——那些输入就是要补的测试。

mock 的纪律：隔离依赖，不隔离被测逻辑

mock 用来隔离外部依赖（数据库、网络、第三方服务、时间），让测试快、稳、可重复。但 mock 容易被滥用：

• 合理 mock：被测代码依赖的外部副作用（真连库太慢、真发邮件会骚扰人）。mock 掉它们，专注测被测逻辑。
• 过度 mock：把被测对象自己的依赖链也 mock 掉，导致测试退化成"测 mock"——你 mock 了 db.save 返回固定 id，又只断言"调了 save"，那其实什么都没测。