JavaScript 测试最佳实践：一份 24k Star 的完整指南

写代码谁都会，但写出靠谱的测试代码，很多团队都栽过跟头。GitHub 上有个项目，专门解决 JavaScript 和 Node.js 的测试难题，Star 数已经到了 24,606。这个项目叫 javascript-testing-best-practices，作者是 Yoni Goldberg，一个专门做 JavaScript 咨询的工程师。

这个项目不是库，也不是框架，是一份纯文档。它整理了 50 多条测试最佳实践，从最基础的测试结构，到前端、后端、CI 流程，全都覆盖了。

为什么这份指南值得看

很多团队写测试就是照着模板抄，能跑通就行。但测试代码的质量直接影响项目的可维护性。这份指南把测试这件事拆解成了具体的规则，每条都有正例和反例，看完就能用。

指南分成六个部分。第一个部分是黄金规则，核心思想就一句话：测试代码要简单、直观，看一眼就知道在测什么。后面的规则都是从这个原则衍生出来的。

测试结构的基本功

测试命名是最容易被忽视的地方。指南建议每个测试名包含三个要素：测的是什么、什么场景、期望结果是什么。比如"When no price is specified, then the product status is pending approval"，比"Add product"这种名字清楚太多。

测试代码的结构也有讲究。AAA 模式（Arrange-Act-Assert）是业界公认的写法：先准备数据，再执行操作，最后断言结果。三段分开，逻辑清晰。

还有一个原则是黑盒测试。只测公开接口，不测内部实现。理由很简单：内部实现随时可能改，但公开接口的行为相对稳定。测内部实现会导致重构时一堆测试失败，但功能其实没问题。

选对测试替身

测试替身（Test Double）是绕不开的话题。指南明确建议优先用 Stub 和 Spy，少用 Mock。区别在于：Mock 关注的是"有没有调用某个方法、传了什么参数"，这是在测内部实现；Stub 和 Spy 关注的是"在某个场景下，系统行为是否符合预期"，这才是测需求。

比如测试"删除商品时是否发了邮件"，用 Spy 监控邮件发送行为是合理的，因为"发邮件"是业务需求。但如果用 Mock 验证"删除方法有没有调用数据库的 delete 方法"，那就是在测实现细节了。

输入数据别偷懒

很多测试用"Foo""bar"这种假数据，看起来能跑通，但到了生产环境就出问题。指南建议用 Faker 这类库生成真实感的数据，比如真实的手机号、用户名、地址。这样能提前发现那些只在特定输入下才会暴露的 bug。

更进一步的做法是属性测试（Property-based Testing）。用 fast-check 这样的库，自动生成几百种输入组合来测试同一个方法，覆盖面比手动写几个测试用例强得多。

后端测试的要点

对于 Node.js 后端，指南有几个实用建议。

首先是组件测试（Component Testing）。比单元测试大，比端到端测试小。针对整个微服务的 API 来测，内部依赖用真实的（比如内存数据库），外部依赖用 Stub 隔离。这种测试性价比最高。

其次是中间件测试。很多人觉得中间件太小不用测，但中间件影响所有请求，一个 bug 就是全局性的。用 node-mocks-http 可以直接构造 req、res 对象来测，不需要启动整个 Express 服务。

还有数据隔离的问题。每个测试应该自己创建数据、自己清理，不要依赖全局的种子数据。否则测试之间会互相干扰，调试起来非常痛苦。

前端测试和 CI

前端测试部分主要讲组件测试和端到端测试。指南建议用快照测试时只用内联快照，不要存大文件。外部快照文件动不动上千行，改一个空格就挂，维护成本太高。

CI 部分强调测试标签。给测试打上 #cold、#sanity 这样的标签，开发时只跑快速测试，提交 PR 时再跑完整测试套件。这样不会因为等测试而打断开发节奏。

静态分析和混沌工程

除了写测试，指南还建议用 SonarQube 或 Code Climate 做静态分析，能发现代码复杂度、重复代码这些问题。

更有意思的是混沌工程的建议。用 node-chaos 这样的工具模拟 Node.js 进程的各种异常情况：内存溢出、事件循环阻塞、未捕获的异常。提前发现系统在极端情况下的表现，比等生产环境出问题强。

总结

这份指南的价值在于它的系统性。50 多条规则覆盖了测试的方方面面，每条都有具体的代码示例。不管你是刚接触测试的新手，还是有经验的开发者，都能从中找到可以立即改进的地方。

项目是纯文档，没有代码依赖，随时可以去看。如果你正在为项目的测试质量发愁，这份指南值得花时间读一遍。

以立即改进的地方。

项目是纯文档，没有代码依赖，随时可以去看。如果你正在为项目的测试质量发愁，这份指南值得花时间读一遍。