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();

ブラウザのテストから得られた上記のようなスニペットは、ほぼ確実に間違っています。UI が表示される前に、さまざまなプロセスやスレッドで発生すべき多くのイベントがあります。

すべきこと

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

SubmitTestPasswordForm();
WaitUntilCredentialPromptVisible();

上記の修正は、WaitUntilCredentialPromptVisible() が UI を実際にチェックしないという前提のもとで正解です。「フォーカスの喪失」や「ウィンドウがフォアグラウンドになった」などの外部 UI イベントに依存しないようにする。ブラウザ ウィンドウがアクティブなときにのみプロンプトが表示される実装を想像してください。このような実装は適切ですが、実際のウィンドウをチェックすると、テストが不安定になります。

修正後の段階

テストが修正されたら、ローカルで数百回実行します。Flakiness Portal を確認してください。