回答。

Flakyテストとは、コードに変更がないにもかかわらず、外部要因によって通過したり失敗したりするテストです。これは自動化への信頼を損ない、CI/CDプロセスを難しくします。

問題の歴史: Flakyテストの問題は、大量のE2E、統合、UIテストの登場とともに、環境や依存するサービスの安定性が保証されない状態で生じました。当初、これらの失敗は無視されたり、「手動で再実行」されたりしました。

問題:

• Flakyテストは、自動テストの信頼性を低下させます。
• 開発者は、実際の失敗を未解決と見なして見逃すようになります。
• テストのサポート時間が増加し、不安定な結果を手動で調査する必要があります。

解決策:

1. Flakyテストの別個の管理。 ラベル付け（例えば、@FlakyTest）または別のカテゴリに分類します。
2. 自動再実行。 テストが失敗した場合、X回再実行します—失敗しない場合は、そのテストを不安定としてマークします。
3. 不安定の原因分析: ログ、状態スナップショット、リソースモニタリングを使用します（例えば、不安定なネットワーク、キュー、GCの動作など）。
4. 段階的修正: テスト環境の改善、シナリオの簡素化、不安定な依存関係のモッキング。

自動再実行のコード例:

import pytest
@pytest.mark.flaky(reruns=3, reruns_delay=2)
def test_random_fail():
    ... # テストコード

主な特徴:

• Flakyテストを本当の失敗と区別することが重要です。
• 単に「すべてを再実行」するべきではありません—本当のバグを見逃してはいけません。
• テストの状態を定期的に分析し、文書化すべきであり、黙認してはいけません。

ひっかけ質問。

Flakyテストは常にインフラストラクチャの問題か？

いいえ、Flakyはビジネスロジックのエラー、コードのレース、非同期性、または時間の扱いの誤りによって引き起こされることがあります。

失敗したテストを再実行するだけで十分か？

いいえ、リトライは問題を隠すだけです。原因を特定し、修正する必要があります。

すべての不安定なテストを削除すべきか？

いいえ、これらを一時的に隔離し、原因を修正する必要があります。単に永遠に除外すべきではありません。

一般的な誤りとアンチパターン

• Flakyを無視し、重大なバグを見逃すことにつながる。
• 原因分析なしに大量のリトライ。
• 重要なテストをFlakyとしてマークし、修正のアクションを取らない。

生活の例

ネガティブケース

プロジェクトではFlakyテストを単にマークし、問題を「解決不可能」として触れなくなりました。

利点:

• 偽の「赤い」ビルドの数が減少

欠点:

• 実際のバグが本番環境に流れる
• 結果を手動で確認する必要が常にある

ポジティブケース

各不安定なテストに自動再実行と内部の不安定性管理を導入しました。原因の定期的な共同レビューを行い、バグを蓄積されるにつれて修正しました。

利点:

• テストシステムの安定性が徐々に改善される
• 新しいFlakyの迅速な検出と修正

欠点:

• 不安定性の分析に定期的なリソースが必要