JS异步测试关键在于用有限用例覆盖临界点：超时、竞态、取消、状态断裂、错误吞没；围绕最小闭环UI组件（如带debounce搜索框），通过mock精确控制Promise生命周期，按状态流设计四类核心场景测试，并落实timeout、async/await、清理等基础设施。
JS 异步代码测试综合实战演练项目，关键不在写多少用例，而在于用有限用例覆盖真实运行中容易出错的临界点：请求超时、竞态覆盖、取消中断、状态流转断裂、错误吞没等。项目应围绕一个典型异步组件（如带搜索建议的输入框、分页数据列表或表单提交器）展开，聚焦“可控制、可观察、可断言”三原则。
一、选一个有真实异步行为的最小闭环组件
不从空函数或工具方法起步，而是选定一个用户能感知状态变化的 UI 组件，例如：
- 一个搜索输入框：输入后 debounce 300ms 发请求，展示 loading、结果列表、错误提示
- 它内部调用
fetchSuggestions(query)，该函数返回 Promise，可能 resolve 数据、reject 错误、或被 abort - 组件自身维护
{ loading: false, results: [], error: null }状态，并响应用户交互（清空、重试、取消）
这个闭环足够小，但已包含发起、等待、响应、清理全部阶段，是边界测试的理想载体。
二、用 mock 精确控制 Promise 的生命周期
禁用真实网络和定时器，所有异步源头都由测试主动注入时机：
- 模拟立即成功：
jest.mock('./api', () => ({ fetchSuggestions: () => Promise.resolve(['a', 'b']) })) - 模拟 200ms 后失败：
jest.mock('./api', () => ({ fetchSuggestions: () => new Promise((_, reject) => setTimeout(() => reject(new Error('Network timeout')), 200)) })) - 模拟 AbortController 中断：
const controller = new AbortController(); fetch(..., { signal: controller.signal }); controller.abort();，再验证是否未触发setState
每个测试只改一个变量（延迟、resolve/reject、abort 时机），确保因果清晰。
三、按状态流设计四类核心测试场景
不测“能不能跑通”，而测“在什么条件下会断掉”：
- 超时路径：设置组件 timeout 为 150ms，mock 接口延迟 200ms，断言最终 state.error 包含 'timeout'，且 loading 变为 false
- 竞态覆盖：先输 "re"（触发请求 A），立刻改为 "react"（触发请求 B）；断言最终 results 是 B 的结果，且 A 的回调未执行（检查 mock.calls.length === 1）
-
取消执行：发起请求后立即调用组件暴露的
cancel()方法（或点击取消按钮），断言 loading 恢复为 false，error 为空，且无 setState 调用 -
状态完整性：用
await waitFor分三步断言——输入后 loading:true → 请求返回后 loading:false & results 非空 → 手动清空后 results:[], loading:false, error:null
四、补全基础设施与验证习惯
让测试真正健壮，还需两处落地：
-
显式 timeout：每个
test加{ timeout: 1000 }，避免 Jest 默认 5s 掩盖响应缓慢问题 -
禁用 done 回调：统一用
async/await + waitFor，错误堆栈指向具体断言行，不跨回调丢失上下文 -
清理副作用：测试后调用
jest.clearAllMocks()和cleanup()（React Testing Library），防止 mock 状态污染下一个用例
不复杂但容易忽略：每次运行前确认 mock 已启用、act 已包裹异步更新、waitFor 有明确超时值。实战项目跑通这四类用例，就已覆盖 90% 的线上异步故障场景。
