第 2 集:由 Vasilii 在慕尼黑创作(2019 年 5 月)
上一集
不稳定测试是 Chrome 中的一个常见问题。它们会影响其他开发者的工作效率,并且会逐渐停用。停用的测试意味着测试覆盖率降低。
分类阶段
目录的所有者负责修复不稳定的测试。 如果您收到有关不稳定的测试的 bug,请花几分钟时间并注释出问题所在。如果您有旧的不稳定测试,但不清楚哪里出了问题,请尝试直接重新启用该测试。如果错误在其他组件中显然存在问题,请尽快重新分配该 bug。 该组件的所有者应该对失败情况做出更明智的判断,
调试阶段
许多命令行标志对于修复不稳定的测试很有用。例如,--enable-pixel-output-in-tests
将呈现实际的浏览器界面。
提供后备工具,前提是调试程序使不稳定问题消失。在调试程序下,测试有可能始终不稳定。在这种情况下,日志语句或 base::debug::StackTrace
会很有帮助。
除了生产代码中的 bug 之外,还要注意 EXPECT__*
失败的常见原因:
- 预期不正确(例如,安全页面表示 HTTPS;可以是 localhost)。
- 因测试未等待适当事件而导致的竞态条件。
[请勿测试实现][not-implementation],而是测试行为。
// It takes 2 round trips between the UI and the background thread to complete.
SyncWithTheStore();
SyncWithTheStore();
CheckTheStore();
将来,这两次往返可能会变为三次,导致测试不稳定。不过,只有商店状态是相关的。请改为使用观测器 (observer) 存储存储区。
请注意以下常见模式:
Submit TestPasswordForm(); // Wait until things settle down. RunLoop().RunUntilIdle(); CheckCredentialPromptVisible();
来自浏览器测试的上述代码段几乎肯定是错误的。许多事件应该发生在不同的进程和线程中,然后某个界面才会显示。
以下解决方法正确:
SubmitTestPasswordForm(); WaitUntilCredentialPromptVisible();
上述修正是正确的,前提是 WaitUntilCredentialPromptVisible()
实际上不会检查界面。浏览器测试不应依赖于外部界面事件,例如“焦点丢失”或“窗口变为前台”。设想一个实现,其中提示仅在浏览器窗口处于活动状态时显示。这样的实现是正确的;但是,检查实际窗口会使测试不稳定。
修复后阶段
修复测试后,在本地运行数百次。敬请关注 Flakiness 门户。