介绍不稳定性测试缓解工具
介绍
本文介绍了一个全新的 Gradle 插件和构建扫描改进，旨在缓解您的不稳定性测试。
不稳定性测试会通过阻止 CI 管道并导致不必要的故障调查来扰乱软件开发周期。不健康的团队靠重新运行构建为生，有时甚至需要运行多次才能使更改通过。Martin Fowler 对非确定性测试的评论值得一读。
为了从您的组织中消除这种“寄生虫”，您必须识别、优先处理并修复您的不稳定性测试。
缓解不稳定性测试 #
有许多巧妙的启发式方法可以帮助识别不稳定性测试。您可以运行一些静态分析来证明测试失败理论上不可能导致给定的测试失败。您可以计算从失败到通过的“翻转”次数，并设置一个阈值，超过该阈值则认为测试是不稳定的。
这些启发式方法通常有效，但真的很难做到正确。当您的不稳定性测试检测方法本身不稳定时，就会出现一个大问题——人们不信任该系统，他们会陷入“重新运行并忍受”模式，直到获得他们想要的结果。
在相同的执行环境中重新运行测试是一种在合理怀疑之外识别不稳定性测试的方法。难怪如此多的团队和库都采用了这种简单的策略。它甚至已直接内置到 Maven Surefire 和 Failsafe 中。
这就是我们开发 Test Retry Gradle 插件的原因，该插件会重试失败的测试，以缓解测试的不稳定性。
全新的 Test Retry Gradle 插件 #
您可以使用此 Gradle 配置来重试测试，并可以选择在出现不稳定性时使构建失败
plugins {
id 'org.gradle.test-retry' version '1.0.0'
}
test {
retry {
failOnPassedAfterRetry = true
maxFailures = 42
maxRetries = 1
}
}
plugins {
id("org.gradle.test-retry") version "1.0.0"
}
tasks.test {
retry {
failOnPassedAfterRetry.set(true)
maxFailures.set(42)
maxRetries.set(1)
}
}
该插件有 4 个特别棒的方面
- 无需更改测试源代码。这允许主动检测新的不稳定性测试！
- 您可以使用
failOnPassedAfterRetry控制在遇到不稳定性时构建是失败还是通过。这意味着您可以采用此插件来检测不稳定性测试，而不会使其静默。 - 您可以使用
maxFailures阻止在测试运行中重试一定数量的测试失败后进行重试。如果您的构建遇到许多失败，则很可能存在导致许多测试失败的重大问题，而重试是在浪费资源。 - 测试尽可能在方法级别或更细粒度级别重试——无需重新运行整个测试类！
Gradle Test Retry 插件支持的环境 #
Test Retry 插件开箱即用地支持 Gradle 5.0 及更高版本，并支持以下测试框架
- JUnit4
- JUnit Platform (JUnit 5)
- Spock
- TestNG
在某些情况下，插件必须重新执行通过的上游测试或下游测试（例如，当使用 @Test(dependsOn = {}) 时），以确保在不稳定性测试依赖于其所依赖的测试的状态时的正确性。
有关受支持框架和重试机制的更多信息，请参阅 Test Retry Gradle 插件文档。
如何报告不稳定性测试 #
我们选择报告不稳定性测试的所有离散执行，以最大限度地提高与现有测试报告和 IDE 的兼容性。因此，不稳定性测试报告可能如下所示
我们正在努力使不稳定性测试成为您日常使用的更多工具中的一流测试结果，以明确报告。文档详细介绍了如何在日志、测试报告和流行的 IDE 中报告不稳定性测试。
好消息是，构建扫描已经以清晰准确的方式报告不稳定性测试！
构建扫描对不稳定性测试的支持 #
现在，当 Gradle 和 Maven 构建扫描在同一次构建中多次执行测试，并且结果既有 PASSED 也有 FAILED 时（顺序不限），会将测试报告为不稳定。这允许构建扫描使用内置重试机制（例如 Maven 的 rerun failing tests 选项，如 -Dsurefire.rerunFailingTestsCount=2）或您的自定义重试机制来报告不稳定性测试。
识别和静默不稳定性测试只能治标不治本。很可能存在一些实际的并发或性能问题，给您的客户带来痛苦——您必须分析不稳定性测试的执行情况以修复它们。您可以在我的博客文章中阅读更多关于在 Maven 和 Gradle 构建中分析不稳定性测试的信息。
结论 #
我们希望全新的 Test Retry Gradle 插件和全新的不稳定性测试分析功能能够帮助您根除不稳定性测试。
请在 Twitter 上告诉我们您的想法。