Chromium Chronicle #2：對抗測試不穩定的

第 2 集：慕尼黑的瓦西里 (Vasilii) (2019 年 5 月)
上一集

不穩定測試是 Chrome 的常見問題。他們 可以提高其他開發人員的生產力，並隨著時間的推移而停用。 停用測試代表測試涵蓋範圍會降低。

分類階段

目錄的 OWNERS 會負責修正不穩定的測試。 如果您收到錯誤測試相關錯誤，請花幾分鐘時間 評論發生錯誤之處。如果測試版本較舊 如果系統不清楚問題所在，請直接重新啟用測試。 如果其他元件明顯有問題，請盡快重新指派錯誤。 該元件的擁有者應更明確地判斷失敗情形

偵錯階段

許多指令列標記都適合 修正不穩定的測試例如：--enable-pixel-output-in-tests 會顯示實際的瀏覽器使用者介面

在偵錯工具變成不穩定時，提供備用工具。是 可能的原因是，在偵錯工具下，測試永遠不會中斷。在此情況下， 陳述式或 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 入口網站。