JS异步测试的核心矛盾是真实事件循环的不可控性与测试需即时断言的冲突；解决方式是通过mock、fake timers和waitFor等工具将异步变为可预测、可干预、可断言的白盒流程。
直接说结论：JS异步代码测试的底层原理，不是在“测异步本身”，而是在“控制异步发生的时机 + 确保回调被正确调用”。关键不在于等它跑完，而在于让测试环境能主动干预、观察和断言异步行为。
异步测试的核心矛盾是什么
浏览器或 Node.js 中的真实异步（比如 fetch、setTimeout、Promise.resolve()）依赖事件循环调度——测试代码却想立刻知道“它有没有被调用”“参数对不对”“错误有没有抛出”。但真实环境里，这些操作会跳到任务队列里排队，主线程根本抓不住它们的执行瞬间。
所以测试框架要做的，是把“不可控的调度”变成“可预测的流程”：
- 不真正发网络请求，而是用 mock 拦截 fetch 或 XMLHttpRequest，直接返回假数据
- 不真等 1 秒，而是用 jest.useFakeTimers() 或 sinon.useFakeTimers() 把 setTimeout 冻结住，再手动推进时间
- 不靠“等一秒再断言”，而是用 await waitFor(...)（React Testing Library）或 waitForExpect 等工具，持续检查 DOM 或状态是否达到预期
Promise 和 async/await 怎么测才不踩坑
很多人写 test('should call API', async () => { await myFunc(); expect(spy).toBeCalled(); })，结果偶尔失败——因为 await 只等 Promise resolve，不等微任务清空后的副作用（比如 setState、DOM 更新）。
真正稳妥的做法是分两层确认：
DMap GL地图JSAPI（dmapgl）开发指南。用于编写、审查、调试 DMap 地图 API 代码，涵盖地图初始化、覆盖物渲染、图层管理、事件处理、控件交互等任务。当用户提及 dmap、dmapgl、jsapi‑gl 或相关地图开发需求时自动触发。
- 第一层：确认异步逻辑触发了（例如 mock 的 fetch 被调用了一次，参数正确）
- 第二层：确认副作用生效了（例如组件渲染出加载中文字 → 再渲染出数据，或 state 变成了预期值）
这时候不能只靠 await，得配合 await waitFor(() => expect(...).toBeInTheDocument()) 这类工具，它内部会反复轮询，直到条件满足或超时。
为什么不能用 sleep(1000) 来等异步
看似简单，实则危险：
- 太慢：每个测试加 1 秒，100 个测试就卡 100 秒，CI 构建爆炸
- 不稳定：网络快时 200ms 就好了，你硬等 1000ms；慢时可能要 1200ms，测试就随机失败
- 掩盖问题：如果异步根本没触发，sleep 后断言还是 fail，但你不知道是逻辑错、mock 漏了，还是 timing 不对
真正的异步测试，追求的是“确定性”——不管机器快慢、网络好坏，只要逻辑正确，测试就稳过。
一句话总结测试思路
把异步操作从“黑盒运行”变成“白盒可控”：拦截它、触发它、观察它、断言它。不跟事件循环赛跑，而是请它坐下来，按你的节奏一步步演。
