# Elixirの不安定なテスト {#elixir-flaky-tests}

> [!IMPORTANT]
> **要件**
>
> - テスト実行を報告するには、<.localized_link href="/guides/get-started/elixir-project">Elixirの共通セットアップ</.localized_link>を完了してください

不安定なテストとは、同じコードで複数回実行した際に異なる結果（合格または不合格）を生み出すテストのことです。これらはテストスイートへの信頼を損ない、誤った失敗の調査に開発者の時間を浪費させます。Tuist は不安定なテストを自動的に検出し、経時的な追跡をサポートします。


![Phoenixアプリケーションの不安定なテスト](/images/guides/features/elixir/flaky-tests.png)

## 不安定な検出の仕組み {#how-it-works}

Tuistは次の2つの方法で不安定なテストを検出します。

### テストの再試行 {#test-retries}

ExUnitは各テストを1回だけ実行するため、断続的に失敗するテストは壊れているテストと同じように見えます。再試行を有効にすると、Hexパッケージは設定した回数まで失敗したテストを再度実行します。再試行で合格したテストは不安定として報告され、すべての失敗したテストが最終的に合格すれば実行は成功します。

再試行はデフォルトで無効です。有効にするには、`mix.exs`内の既存のTuistオプションに`test_retries`を追加してください。

```elixir
tuist: [project: "account/project", cache: true, test_retries: 2]
```

または、フラグまたは環境変数を使用して単一の実行に対して指定します。

```bash
mix test --retries 2
TUIST_TEST_RETRIES=2 mix test
```

フラグは環境変数より優先され、環境変数は`mix.exs`より優先されます。

失敗したテストのみが再度実行され、その動作は`mix test --failed`と同じです。ダッシュボードには各テストの試行回数と所要時間が表示されます。`--max-failures`によりExUnitが早期に停止した実行は再試行されません。失敗したテストがすべてタイムアウトした実行も再試行されません。各再試行で再びすべてのタイムアウトを待つことになるためです。また、`--warnings-as-errors`を使用した場合や、umbrellaプロジェクトのルートから実行した場合も再試行はスキップされます。`mix test`はこれを強制しなくなるため、umbrella内のいずれかのアプリケーション内でテストを実行して再試行してください。

![不安定なExUnitテストとその履歴](/images/guides/features/elixir/flaky-test-case.png)

### クロスラン検出 {#cross-run-detection}

テストの再試行を行わなくても、Tuistは同じコミットに対する異なるCI実行の結果を比較することで不安定なテストを検出できます。あるCI実行ではテストが合格しても、同じコミットおよびスキームラベル（`--scheme`）の別の実行では失敗する場合、その失敗した実行は不安定としてマークされます。

これは、再試行で捕捉できるほど一貫して失敗しないものの、断続的なCI失敗を引き起こす不安定なテストを検出するのに特に役立ちます。

## 不安定なテストの管理 {#managing-flaky-tests}

### 自動クリア {#automatic-clearing}

検出とクリアはプロジェクト上の **自動化アラート** を介して実行されます。すべてのプロジェクトにはデフォルトで「不安定なテスト検出」自動化が設定されており、その *トリガー* はテストを不安定としてマークし、*リカバリー* はテストが再トリガーされずに設定されたリカバリー期間（デフォルト **14 日**）を経過するとフラグを解除します。**設定 → 自動化** で編集して、リカバリー期間を変更したり、リカバリーアクション（例：テストの隔離も解除する）を変更したり、リカバリーを完全に無効にしてテストを手動でクリアするまで不安定なままにしておくことができます。

### 手動管理 {#manual-management}

テストケースの詳細ページから、テストを不安定として手動でマークまたはマーク解除することもできます。これは以下のような場合に役立ちます。
- 修正作業中に既知の不安定なテストを認識したい場合
- インフラストラクチャの問題によりテストが誤ってフラグ付けされた場合


## 不安定なテストの隔離 {#quarantining}

隔離により、修正中に不安定なテストがCIをブロックすることを防ぎます。ダッシュボードのテストページで状態を**ミュート**または**スキップ**に変更するか、**設定 → オートメーション**の下でオートメーションを設定し、テストが不安定になったときにミュートまたはスキップし、回復したら再度有効にします。テストを実行する前に、`mix test`はプロジェクトのすべての隔離されたテストを読み込んで適用します。

- **ミュート**: テストは実行され、失敗は報告されますが、失敗がミュートされたテストのみの場合、実行は合格となります。再試行は失敗したミュートテストを再度実行するため、不安定なテストは合格して不安定として報告される可能性があります。
- **スキップ**: テストは実行されません。`mix test`は実行開始前にスキップされたテストを一覧表示します。

```text
Tuist: skipping 1 quarantined test:
  MyApp.CheckoutTest: create_order/2 times out
Tuist: 1 muted test run, and their failures do not fail the run.
```

ミュートされていないテストが失敗した場合、または`--max-failures`によりExUnitが早期に停止した場合、実行は通常どおり失敗します。

> [!WARNING]
> **制限事項**
>
> - 隔離を適用するのはHexパッケージの最近のバージョンのみです。以前のバージョンはミュートおよびスキップされたテストを他のテストと同様に実行するため、ミュートされたテストの失敗は実行を失敗させます。依存する前に`tuist_ex`を更新してください。
> - ミュートされたテストは、`--warnings-as-errors`を使用する場合や、umbrellaプロジェクトのルートから実行する場合は適用されません。その場合、それらの失敗は実行を失敗させます。代わりにumbrellaの各アプリケーション内でテストを実行してください。
> - スキップはモジュールではなく、describeブロックと名前でテストを一致させます。別のモジュールで同じdescribeブロックと名前を持つテストもスキップされます。[スキップがテストを選択する方法](#how-skipping-selects-tests)を参照してください。
> - `--only`、`--include`、または`path:line`で選択した場合、あるいは`test`で宣言されていないテスト（StreamDataの`property`など）の場合、スキップされたテストでも実行されます。
> - `mix test`が隔離されたテストを読み取れない場合、すべてのテストを実行し、すべての失敗をカウントします。
> - 公開プロジェクトであっても、隔離されたテストを読み取るには認証情報が必要です。`TUIST_TOKEN`、`mix tuist.login`セッション、または継続的インテグレーションのIDトークンがない実行では、隔離は適用されません。これには、通常シークレットなしで実行されるフォークからのプルリクエストも含まれます。
> - `--cover`を使用する場合、スキップされたテストは削除扱いとなり、そのテストのみがカバーしていた行は未カバーとして報告されます。
>
> `mix test`は、サマリーの後に、誤ってスキップから除外されたテストと、それでも実行されたスキップされたテストの名前を表示します。

### スキップがテストを選択する方法 {#how-skipping-selects-tests}

スキップされたテストは、フルネームに対するExUnitフィルター（例: `--exclude "test:test create_order/2 times out"`）によって除外されます。ExUnitフィルターはモジュールも一致させることができないため、次のようになります。

- 別のモジュールで同じdescribeブロックと名前を持つテストも除外されます。`mix test`は実行後にそれらのテストの名前を表示します。
- `--only`、`--include`、または`path:line`で選択したテストは、ExUnitが除外フィルターの後に包含フィルターを適用するため、スキップされていても実行されます。`test`で宣言されていないテスト（StreamDataの`property`など）も同様です。`mix test`は実行後にそれらのテストの名前を表示します。

### 隔離されたテストを再度実行する {#running-quarantined-tests-again}

修正を確認するなど、すべてのテストを実行してすべての失敗をカウントするには、`--no-quarantine`を渡します。

```bash
mix test --no-quarantine
```

後の実行に含めるには、テストのページで状態を**有効**に戻してください。スキップされたテストは、再度実行されるまで新しい結果を生成しません。

`mix test`が隔離されたテストを読み取れない場合、警告を表示してそれらを除くすべてのテストを実行します。認証情報または構成済みプロジェクトがない場合、警告なしですべてのテストを実行します。

Hexパッケージはまだ新しいテストのストレステストを行いません。

## Slack通知 {#slack-notifications}

Slack連携で<.localized_link href="/guides/integrations/slack#flaky-test-alerts">不安定なテストのアラート</.localized_link>を設定し、テストが不安定になった際に通知を受け取りましょう。


## 不安定な状態のクエリ {#querying}

データはHTTP経由で利用できます。ルート、フィルター、レスポンスフィールドの完全な一覧については、APIリファレンスの[テストケースエンドポイント](https://tuist.dev/api/docs#tag/test-cases)を参照してください。テストケースを不安定としてマークまたは解除するには、`is_flaky`を指定して`PATCH /api/projects/{account_handle}/{project_handle}/tests/test-cases/{test_case_id}`を送信するか、`update_test_case`モデルコンテキストプロトコルツールを使用してください。