JavaScript代码可测试的核心在于职责清晰、依赖显式、副作用可控；应抽离副作用至参数或回调，避免隐式调用fetch、修改全局变量等，导出具体函数而非默认对象以提升可测性与Tree-shaking效果。
JavaScript 代码是否“可测试”，不取决于用了什么测试框架，而取决于它是否容易被隔离、被控制、被断言——核心是函数职责清晰、依赖显式、副作用可控。
把副作用抽离到参数或回调里
测试最怕遇到隐式副作用：比如直接调用 fetch、修改全局变量、操作 document。这类代码一跑就发请求或改页面，单元测试根本没法稳定执行。
实操建议：
- 把外部调用（如 API 请求）抽象成函数参数，例如：
loadUser(fetchFn)而不是硬编码fetch('/api/user') - DOM 操作封装成独立函数，并通过参数接收目标节点，避免内部直接写
document.getElementById - 时间相关逻辑（如
new Date()）用参数传入时间戳，方便在测试中固定时间点
示例：
立即学习“Java免费学习笔记（深入）”；
function formatTimestamp(timestamp, now = Date.now()) {
return now - timestamp < 60000 ? '刚刚' : new Date(timestamp).toLocaleString();
}测试时可传入固定值：formatTimestamp(1710000000000, 1710000060000)，结果确定，无需 mock。
避免在模块顶层执行逻辑
Node.js 或 ES 模块加载时，顶层代码会立即运行。如果这里包含初始化、定时器、网络请求，模块一引入就触发副作用，测试文件还没开始跑，环境可能已被污染。
常见错误现象：
- 测试报错
TypeError: fetch is not defined（因为顶层用了未 mock 的fetch） - 多个测试用例之间状态串扰（比如共享的
let cache = {}在顶层）
正确做法：
- 所有业务逻辑封装进函数或类方法，模块只做导出，不主动执行
- 初始化逻辑放到明确的
init()函数里，由使用者按需调用 - 配置对象用
const config = {...}声明，但不要在顶层调用loadConfigFromServer()
用纯函数优先，减少 this 和闭包依赖
带 this 的方法（尤其 class 内部）和强依赖闭包状态的函数，测试时需要构造完整上下文，mock 成本高、易出错。
实操建议：
- 优先写无状态、无 this 的普通函数，输入决定输出，比如：
calculateTotal(items, taxRate) - 如果必须用 class，把核心计算逻辑拆成静态方法或独立函数，便于单独测试
- 避免在闭包里缓存状态（如
let count = 0; const inc = () => ++count），测试难以重置
对比：
// ❌ 难测：闭包状态 + 无参数
const createCounter = () => {
let count = 0;
return () => ++count;
};
<p>// ✅ 可测：状态外置，行为纯化
const increment = (count) => count + 1;导出具体函数，别只导出默认对象
很多项目习惯只导出一个默认对象：export default { init(), start(), stop() }。这会让测试无法 import 单个函数，只能整块 mock，丧失细粒度控制能力。
性能与兼容性影响：
- Tree-shaking 效果差：即使只用
init，整个对象仍可能被打包进去 - ESM 动态 import(
'./module.js') 返回的是命名空间对象，取属性不如直接 import 名称直观
正确写法：
export function init() { ... }
export function start() { ... }
export function stop() { ... }
// 不要 export default { init, start, stop }测试时可精准导入：import { init } from './app.js'，不污染其他导出，也方便 jest.mock 局部替换。
真正难的不是写 test 文件，而是让被测代码不抗拒被测——它得愿意交出控制权，而不是把 fetch、Date、localStorage 全锁死在自己身体里。
