验证重试机制的核心是用可控mock替代依赖并记录调用：前n次reject、第n+1次resolve，断言mock.calls.length等于重试次数+1；配合fake timers验证延迟；覆盖耗尽失败、首次成功、零重试等边界；推荐依赖注入而非mock全局fetch。

要验证带有重试机制的函数在失败时是否按预期重试指定次数，核心思路是：**用可控制的模拟函数（mock）替代真实依赖，记录调用行为，并断言其被调用的次数和参数**。关键在于让被测函数“以为”失败了若干次后才成功，从而触发重试逻辑。

1. 使用 Jest 模拟失败行为并计数调用

假设你有一个带重试的异步函数 fetchWithRetry(url, maxRetries = 3)，它内部调用 fetch()。你可以用 jest.fn() 创建一个模拟的 fetch，让它前 n 次返回 rejected Promise，第 n+1 次才 resolve：

• 用 jest.mock('node-fetch') 或直接 mock 全局 fetch
• 设置 mock 实现：第一次 throw error，第二次再 throw，第三次才返回成功响应
• 调用被测函数后，检查 mockFetch.mock.calls.length 是否等于期望重试次数 + 1（首次 + 重试）

2. 验证重试次数与间隔（可选）

如果重试逻辑包含延迟（如 setTimeout），需确保时间控制可测试：

Alibabacloud Sdk Client Initialization For Java

在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。

下载

• 用 jest.useFakeTimers() 暂停真实定时器
• 调用 jest.runAllTimers() 或 jest.advanceTimersByTime(ms) 推进时间
• 结合 mockFetch.mock.calls.length 断言调用次数，同时用 expect(setTimeout).toHaveBeenCalledTimes(n) 验证延迟调用次数

3. 覆盖边界情况

除了主路径，还需验证异常场景：

• 重试耗尽仍失败：mock 始终 reject，断言最终抛出错误且调用次数 = maxRetries + 1
• 首次就成功：mock 直接 resolve，断言调用次数为 1
• 重试次数为 0：传入 maxRetries = 0，应只调用一次且不重试

4. 不依赖全局 fetch 的更可靠写法（推荐）

避免 monkey patch 全局 fetch，改用依赖注入：

• 将 fetch 作为参数传入函数，或通过类构造器注入
• 测试时传入自定义 mock 函数，完全掌控行为
• 例如：fetchWithRetry(url, { fetch: mockFetch, maxRetries: 2 })

不复杂但容易忽略的是：确保每次 reject 都是**新的 error 实例**（避免引用相等导致意外缓存），且异步流程中 await 正确处理 promise 链。只要 mock 行为可控、调用可观察，重试次数就能准确验证。

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南