JavaScript异步测试应避免回调地狱，需三步重构：先用Promise封装回调API，再用async/await重写逻辑，最后用Jest/Vitest原生支持断言；必须改造业务代码，不可只在测试中模拟；残留回调需隔离验证调用与参数。
JavaScript 异步测试中处理多重嵌套回调，核心不是“忍着写”，而是主动拆解、替换和隔离。回调地狱在测试中会放大问题：断点难设、错误定位模糊、mock 成本高、时序依赖强。真正可行的路径是三步走——先用 Promise 封装原始回调 API，再用 async/await 重写逻辑，最后用 Jest 或 Vitest 的原生异步支持做断言。
把回调函数转成 Promise 再测试
测试前不改业务逻辑？不行。必须先把带回调的函数（如 fs.readFile、数据库 query）包装成返回 Promise 的版本，这样测试才能用 await 等待、用 try/catch 捕获、用 jest.mock 统一拦截。
- 手动封装示例：const readFileAsync = (file) => new Promise((res, rej) => fs.readFile(file, (err, data) => err ? rej(err) : res(data)));
- 第三方库更省事：比如 util.promisify(fs.readFile)，或使用 @types/node 已内置的 Promise 版本
- 测试时直接 mock 整个 Promise 函数，不用管回调参数怎么传、几层嵌套
用 async/await 重写被测函数
如果被测代码本身还保留多层回调，测试就容易失控。应推动重构：把原来的嵌套链（A → B → C）改成线性 async 函数，每步 await 一个 Promise。这样测试函数就变成普通异步函数，可读、可 debug、可覆盖所有分支。
- 不要在测试里写 setTimeout 或 done 回调来“等”嵌套完成
- 避免在 test() 回调里又嵌套 .then() —— 这只是把地狱从业务代码搬进测试文件
- Jest 支持直接 return 一个 Promise 或声明 async test，框架会自动等待它 settle
针对残留回调逻辑做隔离测试
有些老代码或第三方 SDK 无法立刻改造，这时需“围住它”单独测：只验证回调是否被正确调用，参数是否符合预期，不深入嵌套内部。
- 用 jest.fn() 创建模拟回调，传入被测函数，然后 expect(callback).toHaveBeenCalledWith(expectedArg)
- 对 error-first 回调，重点测 err 参数为非 null 时的行为，比如 expect(callback).toHaveBeenCalledWith(new Error('timeout'), undefined)
- 用 jest.useFakeTimers() 控制 setTimeout/setInterval，避免真实等待，加速测试并保证时序可控
调试嵌套回调测试的实用技巧
即便做了封装，偶尔仍需查回调执行流。比起 console.log，更推荐：
- 在关键回调入口加 debugger，配合 Chrome DevTools 的 “Async Call Stack” 查看完整异步调用链
- 用 jest --runInBand --detectOpenHandles 防止未清理的定时器或监听器导致测试挂起
- 给每个测试加 timeout：test('xxx', async () => { ... }, 5000)，避免无限等待卡死 CI
