testing

测试

编写测试和制定测试策略的团队约定。

测试的目的

只有在行为出错时会失败，测试才有存在的价值。这一条标准可以解决大多数关于测试什么的争论：如果你说不出测试能捕获什么 bug，那它就是表面覆盖——每次重构都要付出维护成本，却会在系统已损坏时仍报告成功。

以下所有内容都贯穿着两个结论：

• 断言输出——返回值、抛出的错误、持久化状态。 如果测试唯一的断言是 expect(mock).toHaveBeenCalledWith(…)，那验证的是你刚写的连线，而不是行为。换一种方式正确实现，测试就会失败；保留调用却破坏行为，测试反而会通过。这两种结果都本末倒置。
• 测试决策，而不是代码行。 分支、错误转换、状态转换、边界条件。直通委托或没有条件判断的字段映射无从出错，针对它的测试只会在有人重命名方法时失败。

覆盖率百分比是一个底线指标——它能找出未经测试的文件，却无法区分有价值的测试和空洞的测试。因此，高覆盖率只代表“没有遗漏”，绝不代表“测试质量良好”。

三种模式

对每个功能都从这三方面提问；答案很少能由同一个测试得出。

• 功能——它是否做对了，包括边界情况和失败时的表现？对于带 UI 的功能，这还包括可达性：Tab 顺序应落在合理的位置，控件应有无障碍名称，并且自动化 axe 检查应通过。仅使用键盘的用户遇到死胡同，是功能 bug，而不是外观打磨问题。
• 性能——它能否承受实际遇到的负载和数据量？
• 安全——针对每个端点的具体要求：没有凭据 → 401；凭据有效但角色不符 → 403；其他租户的对象 ID → 404 或 403，绝不能返回对象；输入格式错误或过大 → 400，而不是 500；重复请求 → 429；响应包含 nosniff、帧策略和 HSTS。每项都对应一个测试，每项都覆盖一类功能测试按其设计无法发现的 bug。

约定

• 按行为命名测试：should [outcome] when [condition]。测试在 CI 中失败时，仅看名称就应知道哪里出了问题——像 it('works') 这样的名称会让接手的人不得不阅读测试内容。
• 测试彼此独立，且不依赖顺序。 共享的可变状态会导致测试只在特定顺序下失败，这类问题可能耗费数天。
• 控制时间、随机性和环境。 读取真实时钟的测试会在日期交界、其他时区或闰秒期间失败——总是在最糟糕的时候，而且看起来总像是真 bug。
• 在进程边界模拟，不要在自有单元之间模拟。每个内部模拟都是你需要额外维护的一套实现，且可能逐渐偏离真实实现，直到测试通过时，所依据的系统早已不存在。
• 模拟对象必须完整复现真实响应。 如果生产环境返回 15 个字段，桩却只返回 { id, name }，测试会通过，但代码可能在访问 user.email 时崩溃。使用具有逼真默认值的工厂。
• 切勿为了测试而给生产代码添加方法（_resetForTesting）。应为每个测试创建全新实例；把测试需求写进生产代码，最终会随代码一起交付给用户。
• 不稳定的测试就是失败的测试。 将它隔离后置之不理，会让团队习惯忽略红色状态，而真正的回归问题就会在这种情况下溜过去。
• 按必须响应的速度为测试套件分级。 单元测试在保存时运行，耗时应控制在约 5 分钟以内；集成测试在提交时运行，应控制在 15 分钟以内；端到端测试在拉取请求中运行，应控制在 30 分钟以内；更慢的测试则每晚运行。真正重要的是开发者需要等待多久——一旦内循环耗时超过几分钟，大家就会停止在本地运行，CI 就会成为失败首次出现的地方。

报告发现

报告测试结果或审查覆盖率时，应报告所有发现，包括严重性较低和不确定的项目——按严重性和可信度排序，并交由单独的审核环节决定采取哪些行动。在发现时就进行筛选，会悄无声息地漏掉真实缺陷，读者也无法区分“什么都没发现”和“发现了问题但将其丢弃”。

references/test-reports.md 包含报告结构和严重性定义。

参考资料

参考资料	在以下情况下加载
references/tdd-iron-laws.md	采用测试优先方式工作；遵循红-绿-重构纪律
references/testing-anti-patterns.md	审查现有测试；诊断未能捕获任何问题的测试
references/nestjs-jest-common.md	在 NestJS 后端编写任何 Jest 测试时——先阅读此文件，再阅读下面两个文件
references/nestjs-jest-unit-tests.md	编写 .spec.ts
references/nestjs-jest-contract-tests.md	针对运行中的外部 API 编写 .contract-spec.ts
references/test-reports.md	编写测试报告或缺陷说明