Chromium Chronicle #2：应对测试的不稳定之处

第 2 集：由 Vasilii 在慕尼黑创作（2019 年 5 月）
上一集

不稳定的测试是 Chrome 中的常见问题。他们 影响其他开发者的工作效率，并随着时间推移被停用。 停用测试意味着测试覆盖率会不断缩小。

分类阶段

目录的所有者负责修复不稳定的测试。 如果您收到了有关不稳定测试的错误，请花几分钟时间 说明问题出在哪里。如果您以前执行过不稳定的测试 不确定出了什么问题，请尝试重新启用测试。 如果错误在其他组件中明显存在问题，请尽快重新分配。 该组件的所有者应该能够更好地判断故障，

调试阶段

一些命令行标记对于 修复不稳定的测试例如：--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();

两次往返可能会在未来变为三次，从而导致测试不稳定。 但是，只有商店状态是相关的。而是使用一个观察器来监控 商店。

错误做法

请注意常见的模式，例如：

Submit TestPasswordForm();
// Wait until things settle down.
RunLoop().RunUntilIdle();
CheckCredentialPromptVisible();

上述来自浏览器测试的代码段几乎肯定是错误的。 在不同进程中应该发生许多事件， 线程线程。

正确做法

正确的解决方法如下：

SubmitTestPasswordForm();
WaitUntilCredentialPromptVisible();

鉴于假设 WaitUntilCredentialPromptVisible() 不会实际检查界面。 浏览器测试不应依赖于外部界面事件，例如“失去焦点” 或“窗口变为前台”状态。假设有一个实现， 仅在浏览器窗口处于活动状态时显示。这种实现 是正确的；不过，检查实际窗口会导致测试不稳定。

修复后阶段

测试解决后，请在本地运行数百次。密切关注 Flakiness 门户。