JavaScript代码可测试性的核心在于函数纯度、显式依赖和副作用隔离：纯函数需避免隐式状态依赖，依赖应通过参数注入而非闭包或顶层模块引用，副作用如时间、I/O等需抽象为可替换输入，测试时优先真实渲染而非过度mock，并正确处理异步逻辑。
JavaScript 代码可测试性的核心不在于用什么框架，而在于函数是否纯、依赖是否显式、副作用是否隔离。
函数要尽量纯，避免隐式状态依赖
纯函数指相同输入永远返回相同输出，且不修改外部变量或触发 I/O。这类函数天然容易单元测试，因为不需要 mock 环境。
常见破坏纯度的操作：new Date()、Math.random()、读取 localStorage、直接调用 fetch()、修改传入对象的属性。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 把时间、随机数等“外部输入”作为参数传入，比如
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 版本。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 用依赖注入方式传递关键服务：比如
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 或测试跳过断言直接结束。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 所有返回 Promise 的函数，测试中必须
await它，或用return expect(...).resolves.toEqual(...) - 测试错误路径时，用
await expect(fn()).rejects.toThrow(...)，不要写try/catch+expect - 避免在测试中使用
setTimeout等手动等待；优先用库提供的异步工具，如waitFor（@testing-library）或vi.advanceTimersByTime()（Vitest）
真正难的不是写 test()，而是让业务逻辑不和 DOM、网络、时间、本地存储这些“不可控因素”搅在一起。越早把边界划清楚，后续加测试、改逻辑、换技术栈就越轻松。
