异步行为验证应聚焦任务提交与响应而非等待结果：用verify+timeout检查回调、argumentcaptor捕获参数、awaitility轮询状态变更，并优先使用同步执行器替代真实线程池。
直接验证异步行为本身，而不是等待线程执行完再断言。关键不是“等结果出来”，而是“确认任务被正确提交、触发和响应”。
用 verify + timeout 验证回调是否如期发生
Mockito 的 timeout() 是最轻量的方案，适用于有明确回调接口的场景（如 onSuccess/onFailure）。
- 给 mock 回调对象加 verify(mockCallback, timeout(300)).onSuccess("expected")
- timeout 值要略大于异步逻辑实际耗时（比如 sleep(100) 就设 300ms），避免偶发失败
- 配合 never() 检查错误路径，例如 verify(mockCallback, never()).onFailure(any())
用 ArgumentCaptor 捕获提交参数，确认任务内容正确
线程池本身不暴露任务细节，但你可以捕获它实际执行时传给依赖方法的参数。
- 比如业务代码用 CompletableFuture.supplyAsync(() -> userManager.createUser(dto), pool)，就 verify(userManager, times(n)).createUser(captor.capture())
- 再用 captor.getAllValues() 检查每个 dto 的字段是否符合预期（用户名、状态等）
- 这比“等 createUser 返回后再 assert 结果”更可靠，绕过了线程调度不确定性
用 Awaitility 替代硬编码 sleep，让等待条件更语义化
当需要验证状态变更（如数据库字段更新、缓存写入）时，Awaitility 比 timeout() 更精准。
- 写法类似：await().atMost(2, SECONDS).untilAsserted(() -> assertThat(orderRepository.findById("id")).hasFieldOrPropertyWithValue("status", "PROCESSED"))
- 它会轮询断言，直到满足或超时，不依赖固定延时，也不阻塞整个测试线程
- 适合验证 CompletableFutures.runAsync 或消息发送后产生的副作用
避免真实线程池，用同步执行器替代以消除并发干扰
测试不等于模拟生产环境——多数单元测试应规避真实线程调度。
- 把线程池抽成可注入的依赖（如 ExecutorService executor），测试时注入 Executors.newSingleThreadExecutor() 或更彻底地用 Runnable::run 直接同步执行
- 这样所有逻辑都在主线程跑，verify 和断言顺序完全可控，无需 timeout 或 Awaitility
- 真正需要测“多线程并发效果”的场景（如 ThreadLocal 隔离、竞争条件），再单独设计集成测试
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
