Cucumber 支持通过 retry 配置项对失败的场景进行即时重试，无需手动维护 rerun.txt；该机制适用于因临时性环境问题（如网络抖动、服务短暂不可用）导致的偶发失败。
cucumber 支持通过 `retry` 配置项对失败的场景进行即时重试，无需手动维护 rerun.txt；该机制适用于因临时性环境问题（如网络抖动、服务短暂不可用）导致的偶发失败。
在 Cucumber（尤其是与 TestNG 或 Cucumber-JVM 结合使用时），原生并不支持在 Step Definition 或 @After 钩子中动态触发当前场景重试——即无法在运行时“捕获失败 + 立即重跑本场景”。但 Cucumber 提供了更简洁、声明式的重试机制：通过配置驱动的自动重试（auto-retry），可对整个 Scenario 或 Feature 文件级别设置最大重试次数。
✅ 推荐方案：使用 cucumberOpts.retry
在 Cucumber 运行配置中（如 cucumber.conf.js、testng.xml 或 CLI 参数），启用 retry 选项：
// cucumber.conf.js 示例（Protractor + Cucumber）
exports.config = {
framework: 'custom',
frameworkPath: require.resolve('protractor-cucumber-framework'),
cucumberOpts: {
require: ['steps/**/*.js'],
tags: ['@smoke'],
format: ['pretty'],
retry: 2 // ← 关键配置：每个失败场景最多重试 2 次（共执行 3 次）
}
};? 含义说明：
retry: 2表示当某个 Scenario 执行失败时，Cucumber 将自动重新执行该场景最多 2 次（即原始执行 + 2 次重试，总计最多 3 次）。重试是原子性的，仅针对失败的 Scenario，不影响其他用例。
⚠️ 注意事项与限制
-
retry是 Cucumber-JVM 4.2.0+ 及主流封装器（如protractor-cucumber-framework、cucumber-jsv7+）支持的功能，旧版本需升级； - 重试发生在 Scenario 级别，不是 Step 级别 —— 即整个场景从头开始执行，而非跳过失败步骤；
- 不支持在
@After或 step definition 中条件化控制是否重试（例如“仅当检测到 HTTP 503 时重试”）；若需此类逻辑，仍需结合rerun.txt+ 二次执行，或在 step 中手动throw new PendingException()并配合外部调度； -
specFileRetries（常见于 WebdriverIO/Cucumber 集成）作用于整个 spec 文件（即.feature文件），适合文件级不稳定场景，但粒度较粗，不推荐替代retry。
✅ 最佳实践建议
-
优先使用
retry: N（N 通常设为 1 或 2），简单、稳定、零侵入； - 避免过度依赖重试（如
retry: 5），应定位并修复根本的稳定性问题（如加等待、清理状态、mock 外部依赖）； - 结合日志与报告工具（如
cucumber-html-reporter），确保重试记录可追溯 —— 成功的重试仍会标记为passed (retried)，便于质量分析。
综上，Cucumber 完全支持失败场景的立即、自动、配置化重试，cucumberOpts.retry 是比 rerun.txt 更优雅、更符合现代测试实践的首选方案。
