测试多层嵌套异步回调应将其封装为Promise，用async/await配合expect.assertions断言执行流，mock外部依赖控制返回时机，专注验证最终状态、错误传递和副作用顺序。
测试多层嵌套的异步回调，关键不是“一层层去等回调”，而是把它们转成可控制、可断言的 Promise 形式，再用现代测试工具（如 Jest、Vitest）的异步支持能力来验证逻辑和时序。
把嵌套回调封装成 Promise
原生回调（比如 Node.js 的 fs.readFile 或老式 API）无法直接被 await，必须先包装。这是测试的前提：
- 用
new Promise包一层，把回调的resolve/reject显式暴露出来 - 确保错误路径也触发
reject，否则测试会卡住或误判成功 - 避免在封装里做业务逻辑，只做“转换”，保持纯异步桥接
例如：
function promisifiedReadFile(path) {
return new Promise((resolve, reject) => {
fs.readFile(path, (err, data) => {
if (err) reject(err);
else resolve(data);
});
});
}
用 async/await + expect.assertions 控制执行流
测试函数本身声明为 async，用 await 按顺序调用封装后的 Promise。配合 expect.assertions(n) 确保指定数量的断言被执行，防止漏测成功/失败分支：
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
立即学习“Java免费学习笔记（深入）”；
-
expect.assertions(2)表示至少要有两个expect调用，哪怕某个分支没走，测试也会失败 - 对嵌套中每层可能的副作用（如 mock 函数是否被调用、调用次数、参数是否正确）都加断言
- 不要依赖
setTimeout或done()回调，容易出竞态
Mock 所有外部依赖并控制返回时机
嵌套回调常依赖真实 I/O 或第三方 SDK，测试时必须隔离：
- 用
jest.mock()或vi.mock()替换底层方法，返回可控的 Promise - 对不同测试用例，让 mock 返回 resolve 或 reject，覆盖成功链、中间失败、深层失败等路径
- 用
jest.runOnlyPendingTimers()或await vi.advanceTimersByTimeAsync()模拟时间推进（如果涉及setTimeout类回调）
避免测试“回调结构”，专注测试行为结果
不验证“第几层回调被调用了”，而验证：
- 最终状态是否符合预期（如用户对象是否包含 name 和 orders 字段）
- 错误是否被正确抛出或传递（比如第二层失败时，外层是否收到特定 error message）
- 副作用是否按顺序发生（如日志打印顺序、API 调用参数链是否连贯）
这样即使将来你用 async/await 重写逻辑，测试用例仍可复用，不绑定实现细节。
