6
目前，重试和快速失败有两种选择
--retries=1 --max-failures=1
如果测试不稳定，即使第一次失败也会停止套件。设置--max-failures=2，将在 2 次不稳定的测试失败时失败，重试将通过。
--max-failures=1如果在硬故障时失败，那就太好了，也就是说，不稳定的测试在重试时也会失败
Q
[microsoft/playwright][功能] 重试失败时失败套件
A
回答
3
我开始研究如何实现它并偶然发现了一些东西：我当时正在考虑将重试移到最后 - 这种策略在 Chromium 中对我们来说效果很好：
- 运行所有测试
- 重试失败 1
- 重试剩余的失败 2
- 重试剩余的失败 3
这样，所有不稳定测试都会在运行结束时重试。max-failures如果采用这种策略，建议的语义将使其变得毫无用处。
所以我要回去更好地了解你的用例。你能分享一下为什么你需要它吗？
7
--retries=1确保在 1 次重试后测试将通过
--max-failures=1确保在 1 次测试失败后套件将失败
目前，每次失败都很重要，即使重试后测试会通过
因此，如果 n 个测试都失败，但在重试后通过，则如果这 n 个测试中有 1 个测试在所有配置的重试后都未通过，则失败次数必定为 0 - 这必须将失败次数 +1（带有一些额外的选项，肯定是类似--countHardFails=true的）
6
我理解其原理，但我也想了解用例。假设我们引入了--max-hard-failures=1，但只会在测试运行结束时重试测试，这是否有助于解决您的用例？
2
失败得很快，但速度较慢：）重试是在规范的末尾，但无论如何在套件的中间（甚至是开始），因为规范是在有限的工作者下并行运行的，所以无论如何它都会节省一些时间
啊，是的，即使对于许多不稳定测试的 1 个串行规范，这也会起作用 - 如果至少有一个测试失败，它将节省重试其余测试的时间:)
（是的，我根本不喜欢重试。但遗憾的是，e2e 可能依赖于第三方）
6
等等，使用新策略，我们将首先运行 1000 个测试（还没有快速失败），然后我们将重新运行失败的 10 个测试一次（没有快速失败），然后我们重新运行失败的 5 个测试第三次（现在您将获得快速失败）。所以你说--max-hard-failures你最终运行了 10010 个测试而不是 10015 个，这听起来不像是快速失败。
1
从另一个角度来看 - 10 个规范，每个规范有 10 个测试，使用 10 个浏览器运行 -> 1k 个测试通过--retries=1率为 99.9999%，但如果在第一个规范中失败，则该套件将运行到最后 - 所有 1k 个测试（代替 10 个）套件--max-failures=1将立即失败，（但如果重试失败的测试，整个套件将通过）
我明白，这是一个尽量不射到自己腿上的功能:)
0
我们进行了一次很好的离线讨论，最终将 max-failures 设置为 20 左右 - 这是少数失败的不稳定测试。它仍然可以从损坏的基础设施中尽早恢复，并允许我们将重试推迟到运行结束时。
5
按照上述方法关闭，如果这没有涵盖您的使用案例，请随时打开一个新问题。
7
我们进行了一次很好的离线讨论，最终将 max-failures 设置为 20 左右 - 这是少数失败的不稳定测试。它仍然可以从损坏的基础设施中尽早恢复，并允许我们将重试推迟到运行结束时。
你好@pavelfeldman，我不明白当出现“真正的”测试失败且总测试失败次数<20 时这有什么帮助：套件将失败，但会运行至完成（没有“快速失败”）。
2
只是一个问题 -max-failures会覆盖任何内容retries吗？例如，在我的测试套件中--max-failures=1设置为 1，但我想多次重试单个测试。但一旦我们第一次失败 - 就不会重试
7
只是一个问题 -
max-failures会覆盖任何内容retries吗？例如，在我的测试套件中--max-failures=1设置为 1，但我想多次重试单个测试。但一旦我们第一次失败 - 就不会重试
是的，--max-failures覆盖重试。就多次运行单个测试而言，您可以使用--repeat-each=n。如果与一起使用，那么无论测试通过还是失败，--retries=0它都会运行时间。例如，如果与一起使用，测试仍将至少运行时间，每次测试最多重试 2 次。n--repeat-each=n--retries=2n