第 2 集：在慕尼黑的 Vasilii (2019 年 5 月)
先前集數
不穩定測試是 Chrome 常見的問題。會影響其他開發人員的工作效率，且隨著時間過去停用。停用測試表示測試涵蓋範圍會降低。
實驗階段
目錄的擁有者負責修正不穩定的測試。如果您收到不穩定的測試相關錯誤，請花幾分鐘的時間，針對該錯誤留言回報錯誤。如果您有舊的不穩定測試，但不確定哪裡出現錯誤，請嘗試直接重新啟用測試。如果其他元件中有問題，請盡快重新指派錯誤。元件擁有者應該能更妥善地判斷故障
偵錯階段
許多指令列旗標適用於修正不穩定的測試。舉例來說，--enable-pixel-output-in-tests 會轉譯實際的瀏覽器 UI。
如果偵錯工具導致不穩定，請提供備用工具。在偵錯工具下，測試可能一律不會不穩定。在這種情況下，記錄陳述式或 base::debug::StackTrace 非常實用。
錯誤做法
除了正式版程式碼中的錯誤以外，請多加留意 EXPECT__* 失敗的常見原因：
- 不正確的預期 (例如安全網頁指的是 HTTPS，但可能是 localhost)。
- 因測試未等待適當事件而導致競爭狀況。
[請勿測試實作][非實作]，而是行為。
// 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();
上述瀏覽器測試中的程式碼片段幾乎不正確。 在顯示某些 UI 之前，不同程序和執行緒應發生許多事件。
正確做法
以下為正確的修正方式：
SubmitTestPasswordForm(); WaitUntilCredentialPromptVisible();
上述修正是假設 WaitUntilCredentialPromptVisible() 不會實際檢查 UI 的假設。瀏覽器測試不應依附外部 UI 事件，例如「聚焦遺失」或「視窗成為前景」。假設在實作時，只有在瀏覽器視窗作用中才會顯示提示。這類實作方式正確無誤，但檢查實際視窗是否會導致測試不穩定。
後期階段
測試修正完成後，即可在本機執行數百次。請留意 Flakiness Portal 入口網站。