回答。

テストの再実行メカニズム（リトライ）は、テストパイプラインの安定性を高め、フレークな自動テストに対処するために導入されますが、合理的なアプローチが必要です。

問題の背景 一時的なインフラやフレークエラーに対するワークアラウンドとして登場し、アプリケーションのエラーに関連しない（不安定な環境、ネットワークの問題、APIのタイムアウト）エラーを対象とします。現在、多くのCI/CDシステムが組み込みのretryをサポートしています。

問題点 過剰または制御されていないretryは、実際のバグを隠すか、失敗を「単なる一時的な現象」に変えてしまいます。偽陽性の結果が発生します：テストが通過したように見えても、バグは依然として存在します。

解決策 不安定なテストまたは外部依存型テストにのみリトライを有効にし、タグやマーカーを使用してください。再試行の固定制限（1-2回）を設けます。すべての失敗と再試行の成功をログに記録し、失敗の原因を分析します。

import pytest

@pytest.mark.flaky(reruns=2, reruns_delay=5)
def test_external_api():
    # APIの不安定さのために失敗する可能性のあるテスト
    ...

主な特徴:

トリッキーな質問。

パイプライン内のすべての自動テストを再実行してもよいですか？

これは悪い実践です：実際のバグやテストのアーキテクチャの問題が隠れてしまいます。リトライは一部のテストのための最終手段です。

3回リトライしてもテストが通らない場合はどうすればいいですか？

実行を中止し、不安定性/調査に関するバグをオープンする必要があります。これにより、リファクタリングが必要なトリッキーなエラーが明らかになります。

テストが2回目に通過する場合は、すべてが良好だということですか？

いいえ、唯一の正しい状態は最初の実行での安定した通過です。2回目の通過は問題の指標です（フレークまたはインフラ）。

Jenkinsの全パイプラインに2回のグローバルリトライを設定しました。1ヶ月後、コードのレースコンディションによるバグが蔓延し、チームは「品質が良い」と考えていました。製品は突然、同じバグのために本番環境でクラッシュしました。

利点:

欠点:

外部APIを持つテストカテゴリーにのみリトライを設定しました（タグによって）。他のすべてのテストは一度の実行で厳格に通過します。チームはログを使って再発する失敗を調査し、修正します。

利点:

欠点: