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