直接用ASSERT无法重试，因其失败即终止；需手动循环+return控制重试逻辑，失败时sleep后继续，成功则跳出，最终统一断言并报告重试次数。
为什么直接用 ASSERT 无法满足重试需求
标准 ASSERT 或 EXPECT_* 宏在断言失败时立即终止当前测试用例（或记录失败后继续），不支持“尝试多次再报错”。比如调用一个可能因网络抖动、竞态条件偶尔失败的函数，你希望它最多重试 3 次 —— 这种逻辑必须显式控制流程，不能靠断言本身实现。
常见错误是试图在 EXPECT_TRUE 外面包一层循环，但这样会导致：失败时堆栈指向循环体而非实际断言行；重试次数不统一；无法区分“第 1 次失败”和“第 3 次仍失败”；Google Test 的断言计数也会异常。
用 TEST 内部写带重试的裸循环 + return 控制
最轻量、最可控的方式是在测试函数体内手动展开重试逻辑，配合 return 提前退出。不封装成宏也能清晰表达意图，且调试友好。
- 每次重试前加
std::this_thread::sleep_for（如需等待） - 用普通
if判断结果，失败时继续循环；成功则跳出 - 循环结束后仍失败，再用
ASSERT_* / EXPECT_*报错，并带上重试次数信息 - 避免在循环内直接调用
ASSERT_*，否则第一次失败就终止整个测试
TEST(MyTest, MayFailOccasionally) {
int retry = 0;
const int max_retry = 3;
bool success = false;
while (retry < max_retry && !success) {
auto result = unreliable_function();
if (result == expected_value) {
success = true;
break;
}
++retry;
if (retry < max_retry) std::this_thread::sleep_for(10ms);
}
ASSERT_TRUE(success) << "unreliable_function() failed after " << retry << " retries";
}封装成可读性高的宏：注意 __LINE__ 和作用域陷阱
如果真要宏，核心是让每次重试都在同一作用域执行，且错误消息能定位到原始调用行。不能把整个 while 块塞进宏里然后展开——那样会破坏变量作用域，也难调试。
立即学习“C++免费学习笔记（深入）”；
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
推荐做法：宏只生成带行号标记的重试块头尾，主体逻辑仍由用户书写，避免隐藏控制流。
- 用
__LINE__生成唯一标签名（如retry_label_##__LINE__），防止嵌套宏冲突 - 宏内不定义新变量（如
retry），而是要求用户传入变量名，或用static局部变量（但注意多线程下不安全） - 绝对不要在宏里用
return，否则调用者函数提前退出，后续断言失效 - 更安全的做法是宏返回
bool，让用户决定是否ASSERT_TRUE
#define EXPECT_RETRY(expr, max_retry) ([&]() -> bool { \
for (int _retry = 0; _retry < (max_retry); ++_retry) { \
if (expr) return true; \
if (_retry + 1 < (max_retry)) std::this_thread::sleep_for(10ms); \
} \
return false; \
}())使用：EXPECT_TRUE(EXPECT_RETRY(foo() == 42, 3)); —— 这样既保持断言语义，又把重试逻辑闭包化，不影响外部作用域。
重试逻辑中容易被忽略的三个细节
重试不是加个循环就完事。真正线上出问题的地方往往藏在边界上：
-
sleep_for时间太短（如1ms）可能根本没缓解竞态；太长（如1s）拖慢整个测试套件 —— 建议从10ms起调，结合具体场景调整 - 被测函数本身是否幂等？比如
send_packet()重试可能造成重复发送，需确认接口设计允许重试 - Google Test 的
ASSERT_*在非 void 函数里会return，若放在重试循环内部，会导致仅执行一次 —— 必须确保断言只在最终判断时触发
重试次数设为 3 是经验阈值，但关键不在数字本身，而在你能否说清“为什么是 3 次而不是 2 或 5”——这背后应该是对失败模式的观察，不是拍脑袋定的。
