使用 `screen.findallbyrole("alert")` 时，若目标元素是异步动态插入 dom（如 toast 组件），直接断言可能因渲染未完成而失败；需配合 `waitfor` 等待所有元素稳定存在。
在基于 DOM 的 Jest 测试中（例如使用 @testing-library/dom），findAllBy* 系列查询方法虽自带一定重试机制（默认约 1000ms 轮询），但其行为依赖于 元素是否真正完成挂载并满足可访问性条件。对于 Toast 这类通过 JavaScript 动态创建、添加、甚至带 CSS 过渡或延迟移除的组件，DOM 更新往往存在微小延迟或异步队列，导致 findAllByRole("alert") 在首次调用时仅捕获到部分（甚至仅最后一个）元素。
你遇到的问题——点击 3 次按钮却只查到 1 个 role="alert" 元素——正是典型的时间竞态：测试执行速度远快于 Toast 的实际 DOM 插入节奏，findAllByRole 在超时前仅观察到最终残留的一个节点（可能是最后一个 toast 尚未被清理，而前两个已快速消失或尚未 commit）。
✅ 正确解法：使用 waitFor 显式等待断言成立
waitFor 会反复执行传入的回调函数（默认超时 1000ms），直到其内部 expect 通过，或超时抛错。它比 findAllBy* 更灵活，适合验证“数量达到 N”或“状态最终一致”等复合条件：
import { screen, waitFor } from '@testing-library/dom';
test('3 toasts appear on 3 button clicks', async () => {
const { user } = getExampleDom();
const successBtn = screen.getByRole('button', { name: /Trigger success toast/i });
for (let i = 0; i < 3; i++) {
await user.click(successBtn); // 推荐 await click（userEvent v14+ 默认返回 Promise）
}
// ✅ 使用 waitFor 确保 3 个 alert 同时存在
await waitFor(async () => {
const alerts = await screen.findAllByRole('alert');
expect(alerts).toHaveLength(3);
});
});⚠️ 注意事项：
- waitFor 内部必须 await 异步查询（如 findAllByRole），否则会立即 resolve 导致断言失效；
- 若 Toast 存在自动关闭逻辑（如 3s 后 remove()），请确保 waitFor 超时时间 > 单个 toast 生命周期，或在测试中临时禁用自动销毁（例如 mock setTimeout 或通过配置项关闭）；
- 避免在 waitFor 外层重复 await screen.findAllByRole(...) —— 它不保证返回全部历史节点，仅返回当前存在的匹配项；
- 清理副作用：每个测试后应重置 DOM（如 document.body.innerHTML = ''）并销毁 Toast 实例，防止状态污染后续测试（可在 afterEach 中统一处理）。
? 进阶建议：为 Toast 组件增加可预测的测试钩子，例如：
- 添加 data-testid="toast" 或 data-state="visible" 属性；
- 暴露 toast.count() 方法供断言；
- 使用 jest.useFakeTimers() 控制自动关闭定时器，提升测试稳定性。
通过 waitFor + 异步断言，你就能可靠地验证动态 UI 的最终状态，让 Toast 测试真正具备确定性与可维护性。
