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

第 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 门户。