Chromium Chronicle #2: テストの不安定さへの対処

エピソード 2: ミュンヘンでの Vasilii（2019 年 5 月）
前のエピソード

不安定なテストは Chrome でよくある問題です。。 他のデベロッパーの生産性にも影響し、やがて無効になることもあります。 テストを無効にすると、テスト カバレッジが狭まります。

トリアージステージ

不安定なテストを修正する責任はディレクトリの所有者にあります。 不安定なテストに関するバグを受け取った場合は、 バグに何が問題なのかをコメントしてください。古いテストが不安定で 原因が不明な場合は、テストを再度有効にしてみてください。 別のコンポーネントで明らかな問題である場合は、できるだけ早くバグを再割り当てします。 コンポーネントの所有者は、障害、

デバッグ ステージ

さまざまなコマンドライン フラグが、 不安定なテストを修正します例: --enable-pixel-output-in-tests 実際のブラウザ UI を表示します。

デバッガによって脆弱性が解消される場合は、フォールバック ツールが用意されています。です。 デバッガを使うとテストが不安定にならないその場合、 ステートメントまたは base::debug::StackTrace が便利です。

すべきでないこと

本番環境のバグ以外の EXPECT__* エラーの一般的な理由に留意してください コード:

  • 想定外の動作（例: セキュリティで保護されたページは HTTPS を意味する。ローカルホストがローカルホストではない可能性がある）。
  • 適切なイベントを待機していないテストによる競合状態。

[実装をテストしません][not-implementation] が、動作をテストします。

// It takes 2 round trips between the UI and the background thread to complete.
SyncWithTheStore();
SyncWithTheStore();
CheckTheStore();

2 回の往復が将来的に 3 回に変更され、テストが不安定になる可能性があります。 ただし、関連するのは店舗の状態のみです。代わりに、モニタリング対象データにはオブザーバーを あります

すべきでないこと

次のような一般的なパターンに注意してください。

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

上記のブラウザテストのスニペットは、ほぼ間違いなく正しくありません。 さまざまなプロセスで発生すべきイベントは多数ありますが、 スレッドダンプがあります

すべきこと

正しい修正は次のとおりです。

SubmitTestPasswordForm();
WaitUntilCredentialPromptVisible();

上記の修正は、 WaitUntilCredentialPromptVisible() は実際に UI をチェックしません。 「フォーカス喪失」など、ブラウザのテストが外部 UI イベントに依存しない 発生した場合です。たとえば、プロンプトにプロンプトを ブラウザ ウィンドウがアクティブな場合のみ表示されます。このような実装は 正解です。ただし、実際のウィンドウを確認すると、テストが不安定になります。

修理後の段階

テストが修正されたら、ローカルで数百回実行します。最新情報を随時ご確認ください。 Flakiness Portal: