JavaScript可测试代码编写指南

小伙伴们对文章编程感兴趣吗？是否正在学习相关知识点？如果是，那么本文《JavaScript如何编写可测试代码？实用原则与工具解析》，就很适合你，本篇文章讲解的知识点主要包括。在之后的文章中也会多多分享相关知识点，希望对大家的知识积累有所帮助！

JavaScript代码可测试性的核心在于函数纯度、显式依赖和副作用隔离：纯函数需避免隐式状态依赖，依赖应通过参数注入而非闭包或顶层模块引用，副作用如时间、I/O等需抽象为可替换输入，测试时优先真实渲染而非过度mock，并正确处理异步逻辑。

JavaScript 代码可测试性的核心不在于用什么框架，而在于函数是否纯、依赖是否显式、副作用是否隔离。

函数要尽量纯，避免隐式状态依赖

纯函数指相同输入永远返回相同输出，且不修改外部变量或触发 I/O。这类函数天然容易单元测试，因为不需要 mock 环境。

常见破坏纯度的操作：new Date()、Math.random()、读取 localStorage、直接调用 fetch()、修改传入对象的属性。

实操建议：

• 把时间、随机数等“外部输入”作为参数传入，比如 formatDate(date = new Date()) 改为 formatDate(date)，测试时传入固定 new Date('2023-01-01')
• 避免在函数内部直接调用 console.log 或 alert；如需日志，接受一个 logger 函数作为参数
• 对象操作优先用解构 + 扩展符生成新对象，而不是 obj.name = 'x'

依赖要显式注入，别藏在闭包或模块顶层

如果一个函数内部直接引用了全局 API_CLIENT 或通过 import { api } from './api' 引入模块，它就和具体实现强耦合，测试时无法替换为 mock 版本。

实操建议：

• 用依赖注入方式传递关键服务：比如 function uploadFile(file, uploader)，测试时传入 { upload: jest.fn().mockResolvedValue({ id: 1 }) }
• 避免在模块顶层执行初始化逻辑（如 const client = createClient(...)），改用工厂函数 createApiClient(config)，测试时可传入不同 config 或 mock 实现
• ESM 中慎用命名导入做“单例式依赖”，更推荐默认导出工厂函数或类

用 Jest + Vitest 做隔离测试，但别过度 mock

Jest 是目前最成熟的 JS 测试工具，Vitest 则更轻量、与 Vite 生态集成更好，两者 API 高度兼容。它们都支持 jest.mock() 和 vi.mock() 来拦截模块依赖。

容易踩的坑：

• jest.mock() 必须在文件顶部调用（不是在 beforeEach 里），否则可能 mock 失败
• mock 深层依赖（如 axios.get）时，确保路径准确：是 jest.mock('axios')，不是 jest.mock('./utils/api')
• 过度 mock 会让测试失去意义——比如 mock 掉整个 UI 组件树后，只测了个空壳，不如少 mock、多用真实渲染（@testing-library/react）

异步逻辑必须明确处理完成信号

忘记 await、漏掉 done() 回调、或没正确处理 Promise rejection，都会导致测试“假通过”或超时失败。

典型错误现象：Timeout - Async callback was not invoked within the 5000ms timeout specified 或测试跳过断言直接结束。

实操建议：

• 所有返回 Promise 的函数，测试中必须 await 它，或用 return expect(...).resolves.toEqual(...)
• 测试错误路径时，用 await expect(fn()).rejects.toThrow(...)，不要写 try/catch + expect
• 避免在测试中使用 setTimeout 等手动等待；优先用库提供的异步工具，如 waitFor（@testing-library）或 vi.advanceTimersByTime()（Vitest）

真正难的不是写 test()，而是让业务逻辑不和 DOM、网络、时间、本地存储这些“不可控因素”搅在一起。越早把边界划清楚，后续加测试、改逻辑、换技术栈就越轻松。

好了，本文到此结束，带大家了解了《JavaScript可测试代码编写指南》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多文章知识！