tdd

テスト駆動開発

TDD は、新たに追加または変更する、観測可能な動作に対する基本的なプラクティスです。そのような本番コードの変更はすべて、失敗する動作テストへの対応として記述する必要があります。

動作を維持するだけの作業は別です。refactoring と reduce-system-complexity は、適切な範囲の動作維持を示す証拠がすべて成功している状態から始め、内部構造の変更中も動作が常に成功する状態を保ちます。フェーズ終了時の PR 準備完了ゲートでは、有効な場合にミューテーションテストを使用してください。有効でない場合は、到達可能性、設定、コントラクト、統合、または運用上の証拠を記録し、ミューテーションを N/A としてください。REFACTOR スライスを無理に RED にするためだけに、失敗するテストや構造上のミュータントを作り出してはいけません。動作を変更する場合、または議論のあるバグを修正する場合は、RED に戻ってください。

このスキルにおけるフェーズとは、個別にマージ可能な、PR 1 件分のスライスを指します。つまり、1 つのブランチと PR に蓄積されたスコープです。複数の PR にまたがる機能や、README.md に記載されたライフサイクルの番号付きフェーズを指すものではありません。

優れたテストの書き方については、testing スキルを読み込んでください。このスキルでは、TDD のワークフローとプロセスに焦点を当てています。ミューテーションを考慮したテスト計画については、mutation-testing スキルを読み込み、正確な情報源としてその resources/mutator-rules.md リソースを使用してください。

---

高速な TDD フィードバックループ（AI のデフォルト）

RED-GREEN-REFACTOR の内部ループでは、関連性の高いフィードバックをすばやく得られるようにしてください。編集のたびにテストスイート全体を実行してはいけません。

RED を始める前に、パッケージスクリプト、テスト設定、ランナーのヘルプを確認してください。リポジトリ独自のコマンドは、汎用的な例より優先されます。

1. リポジトリで定められたウォッチャーの起動タイミングを守る — 最初の編集前に、実証済みのウォッチャーを起動する必要がある場合は、今の時点で一度起動してください。そうでなければ、厳密な TDD では先に RED を記述し、その直後にウォッチャーを起動してもかまいません。リポジトリ固有のタイミングは、以下の汎用例より優先されます。
2. RED — 新規または変更したテストのファイル名／テスト名を指定して実行し、想定どおり失敗することを確認してください。
3. ウォッチャーを慎重に選択するか、再利用する — リポジトリ独自の、テスト済みの watch コマンドを優先してください。実行時グラフを作成するために、関連する開発用ティア全体を一度実行した後、影響を受けるテストのみを再実行することがあります。そのようなコマンドがない Vitest では、インストール済みのバージョンとリポジトリ設定に必要なライブ動作の証拠がある場合に限り、実在するベースを指定した --changed <real-base> --watch を使用してください。
4. GREEN／REFACTOR — 再利用可能な専用ターミナル／セッションで、ウォッチャーを 1 つ起動した状態に保ってください。影響を受けるテストはランナーまたはリポジトリのグラフに選択させ、継続中の GREEN スコープを手作業でより小さく選んではいけません。
5. AI／非対話型の代替手段 — 永続的なウォッチャーを確実に管理できない場合は、編集のたびに、影響を受けるテストと同等のワンショット実行を行ってください。
6. 適切な境界で修正する — 古くなった関係や、新たにグラフから認識できるようになった関係には、再起動またはシードのやり直しを行ってください。import 以外の依存関係／動的な依存関係、設定、グローバルセットアップ、パブリックコントラクト、共有パッケージに不確実性がある場合は、リポジトリ独自のトリガーを追加するか、担当するスイート／ティアまで範囲を広げてください。再起動だけでは、存在しないグラフのエッジは作成できません。
7. PR 準備完了 — すべてのウォッチャーを停止してから、リポジトリのミューテーション／代替証拠に関する方針に従い、watch を使わない PR ゲートを完了してください。モノレポでは、最終ゲートに開発用サブセットだけでなく、設定済みのすべてのプロジェクトと必須の統合／E2E スイートを含めてください。

再利用可能な Vitest ウォッチャーを選択、追加、または変更する前に、resources/vitest-watch-feedback.md を読んでください。シード戦略、ネイティブな検出、見落としやすい点、および必須のライブプロセスの証明について、詳細を定めた正規の資料です。

Vitest のシードセマンティクス

vitest --changed <real-base> --watch は、初回実行では差分によって選択されます。Vitest はこの選択後に VCS セレクターをクリアするため、保存のたびに VCS の影響範囲を再計算し続けるわけではありません。以降の再実行では、保持された Vite モジュールグラフが使用されます。Vitest 4.1.10 の通常の Node/SSR パスでは、初回の変更検出時に、検出されたすべてのテスト仕様が静的に解析されます。そのため、クリーンな状態での初回実行で影響を受けるテストがないと報告された場合でも、インポートされている実装に編集を加えると、そのテストが再実行されることがあります。したがって、以降の再実行の対象が初回に実行されたテストだけに限られるわけではありません。

この Vitest 4.1.10 の実装上の詳細を、他のバージョン、Browser Mode、動的依存関係やインポート以外の依存関係、または任意のリポジトリ構成に一般化しないでください。通常の開発、クリーンなリファクタリングのベースライン、または RED の前に起動するウォッチャーには、動作が実証されているリポジトリ管理下のコマンド（例：pnpm test:watch）を優先してください。リポジトリでは、グラフを構築するために、関連する全ティアを一度だけ安全に実行できる場合があります。厳密な TDD では、RED の後に差分選択が実証されているウォッチャーを起動すると、期待するテストが実際に実行されたことを簡単に確認できます。リポジトリのコマンドを、汎用的な生の Vitest の例に置き換えないでください。

例（リポジトリに合わせて調整してください。必要な動作を満たす既存のコマンドのうち、最初に該当するものを使用します）：

# Repository-owned graph-complete watch, when defined and proven
pnpm test:watch

# Vitest diff-selected initial execution: use only after repository-level proof
pnpm exec vitest --changed origin/main --watch

# Vitest fallbacks: mechanically derived affected sources or one-shots
pnpm exec vitest related src/example.ts --watch
pnpm exec vitest related --run src/example.ts
pnpm exec vitest --changed origin/main --run

# Exact selector: RED/debug only
pnpm exec vitest run tests/example.test.ts -t "rejects empty names"

# Jest: repository/runner changed watch, or affected one-shot
pnpm exec jest --watch
pnpm exec jest --watch --changedSince=origin/main
pnpm exec jest --findRelatedTests src/example.ts --watch=false
pnpm exec jest --onlyChanged --watch=false
pnpm exec jest --changedSince=origin/main --watch=false
pnpm exec jest --runTestsByPath tests/example.test.ts -t "rejects empty names"

# Playwright: runner-selected affected one-shot (heuristic; inspect the selected tests)
pnpm exec playwright test --only-changed
pnpm exec playwright test --only-changed=origin/main

include グロブが開いたままであれば、Vitest は新しい一致するテストファイルをネイティブに検出します。以降の実装の再実行を信頼する前に、新しいテストが実際に実行され、その実装を読み込んでいることを確認してください。ネイティブの検出だけでは不十分であることが実行時の証拠で確認されない限り、カスタムのファイルシステムリスナーを追加したり、再実行 API を呼び出したりしないでください。両方を行うと、新しいテストが二重に実行されることがあります。

vitest related <sources...> は、すべてのソースパスを機械的に導出できる場合に限り、フォールバックとして使用できます。暗黙のうちに空の結果を成功として扱うため、期待するテストが実行されたことを確認してください。--passWithNoTests を根拠として使用しないでください。--standalone は、ファイルフィルターなしで初回の実行をスキップするか、指定されたフィルターだけを使うワークフローに縮小するため、使用しないでください。

ウォッチャーのライフサイクルと自動化の安全性

• 専用の再利用可能なターミナル／セッションでウォッチャーを1つ起動し、内側の開発ループ全体で再利用します。
• 最後の編集後、PR のゲートやタスクの引き継ぎ前に Ctrl+C で停止します。バックグラウンドにウォッチャーを残さないでください。
• 自動化でウォッチャーを起動する場合、タイムアウト時やシグナルによるクリーンアップ時には、直接の親プロセスだけでなくウォッチャーのプロセスグループ全体を終了し、一時ディレクトリを削除します。
• CI、Git フック、終了を前提とする有限の lint／test／build／検証スクリプト、または終了を前提とする別のパッケージスクリプトから、ウォッチコマンドを決して呼び出さないでください。対話型 TTY での裸の vitest、vitest watch、vitest --watch、vitest --watch=true、vitest -w、vitest -w=true など、一般的な形式を検出します。有限の Vitest コマンドでは、vitest run、--run、または --watch=false を指定して確実に終了させます。
• ウォッチサブコマンドまたは有効な watch フラグと有限実行のマーカーが混在するコマンドは、ウォッチモードとして扱います。vitest run --watch と vitest watch --watch=false は有限実行ではありません。
• 唯一の例外は、ウォッチャー自体を対象とする独立したライブ証明用ハーネスです。このハーネスでは、一時的なフィクスチャを使用し、厳格なタイムアウトを設定し、成功時も失敗時もウォッチャーのプロセスグループ全体を終了し、フィクスチャを削除する必要があります。また、そのウォッチ呼び出しを通常の有限なパッケージ／CI コマンドとして公開してはなりません。
• 該当する再実行の後に出力された内容を確認します。古い待機中のマーカー、テスト数がゼロであること、またはテストなしでも成功扱いにするオプションによって成功したプロセスは、根拠になりません。

明示的なウォッチは、TTY がなくても長時間実行されるものであり、CI では有限コマンドになりません。標準入力が TTY で、CI でも Vitest のエージェント検出機能によっても無効化されていない場合、裸の vitest はウォッチモードを既定とすることがあります。有限コマンドを終了させるために、環境の自動検出に決して依存しないでください。他のランナーでは、テスト済みのリポジトリ管理下のウォッチャーを最優先し、次にネイティブの変更／影響範囲選択、完全な機械的導出によるソース一覧を使った依存関係対応の選択、グラフから導出した影響範囲内のパッケージ／プロジェクトの集合、最後に影響範囲を対象とした単発実行の順に選択します。対象を正確に指定するセレクターは、RED／デバッグ専用です。

モノレポ

変更／影響範囲の選択は、リポジトリルートから、プロジェクトで定義されたテストコマンド、ルートの Vitest projects 設定、またはワークスペースの依存関係グラフ全体を管理するモノレポオーケストレーターを通じて実行します。共有パッケージの編集は複数の利用側のテストに影響する可能性があるため、編集対象のファイルだけを根拠に、1つのパッケージに cd したり --project を追加したりしないでください。Vitest またはリポジトリのパッケージ／タスクグラフが、推移的な依存先を含む影響対象プロジェクトの完全な集合を機械的に導出した場合に限り、プロジェクトフィルターを安全に使用できます。

ルート設定に関連するすべてのプロジェクトが列挙されていること、パッケージ間のインポートがグラフ上で認識されることを確認します。ファイルシステムの読み取り、サブプロセスの対象、生成された出力、テンプレート、プロキシ経由で取得される依存関係、型のみの関係、ファイルをスキャンするリポジトリガード、ブラウザーモードのテスト、Docker を利用するティアには、リポジトリ固有のトリガーや個別のコマンドが必要になる場合があります。設定されている場合は、watchTriggerPatterns と forceRerunTriggers を維持します。再起動／再シードで修復できるのは、古くなった関係や、新たにグラフから認識されるようになった関係だけです。グラフで表現できない依存関係については、明示的なマッピングを設定するか、それを管理するスイート／ティアを実行してください。

ウォッチモードは内側の開発ループを高速化するものであり、PR の根拠にはなりません。PR 前の記録は、最終ツリーに対して完了した非ウォッチの全件実行から取得する必要があります。

リポジトリの規則

リポジトリ固有のテスト、カバレッジ、ミューテーション、証拠の鮮度に関する規則が優先されます。対象リポジトリに、より厳格な無効化ルールが定義されていない場合に限り、この配布物の鮮度モデル（panel-review スキルの references/pr-readiness.md）を使用します。この全体向けガイダンスによって、後続の本番コードや該当するテストの変更後に証拠を無効とするリポジトリの規則を、決して緩和してはなりません。

---

RED-GREEN-REFACTOR 開発サイクル

RED：失敗するテストを最初に書く

• 新しい動作や変更された動作については、動作テストが失敗することを確認するまで、本番コードを書かないでください
• テストでは実装方法ではなく、期待する動作を記述します
• テストは正しい理由で失敗する必要があります
• RED を示すには、最も対象を絞ったテストセレクターを実行します。無関係なテストを実行して、内側のループに時間をかけないでください
• テストを確定する前に、意図する動作をミューテータールールに照らして確認します。境界値、ブール値の組み合わせ、等価性、算術演算の恒等式、配列／文字列の操作、オプショナルチェーン、サイドエフェクトを確認してください
• 明らかに不足しているケースはすぐに追加します。期待される動作が製品／ドメイン上の判断を要する場合は、ハーネスの質問機能を使用してください

GREEN：合格に必要な最小限のコード

• テストを合格させるために必要なコードだけを書きます
• テストで求められていない機能を追加しないでください
• その場しのぎの実装も有効です。合格するなら戻り値をハードコードし、その後、三角測量を行います。実際の実装を必要とする 2 つ目のテストケースを追加し、テストで要求されてから一般化してください
• アクティブなフォーカス済みウォッチャー、または関連／影響範囲を対象とする単発コマンドを使用します。対象を広げるのは、フォーカスした動作が GREEN になってからにしてください

REFACTOR：改善点を評価する

• GREEN の後、合格した動作テストを安全網として改善点を評価します
• リファクタリングが該当する場合にのみ refactoring スキルを読み込み、該当しない場合は N/A と記録します
• ワークフローで作業中の基準点をコミットとして使う場合は、リファクタリングの前にそのコミットの承認を得ます
• 小さなリファクタリングのたびに、フォーカスしたテストと影響範囲のテストを合格状態に保ちます。PR 前のゲートでは全テストスイートを実行します

フェーズの PR 対象範囲が完了するまで、必要に応じて RED-GREEN-REFACTOR を繰り返してください。各変更、リファクタリング、コミットの後に、自動ミューテーションハーネスを実行しないでください。ハーネスを実行したかどうかにかかわらず、最終返信ではミューテーションゲートの結果を 1 行で必ず示してください。形式は Mutation: ran, X killed / Y survived (score Z%)、Mutation: N/A — <rationale> ; alternate evidence: <what>、または Mutation: deferred to the PR gate — this slice is not yet PR-ready です。ゲートの記載がなければ、ゲートを記録していないことになります。

フェーズ終了時の PR 準備完了ゲート

実装とリファクタリングのフェーズが完了し、その他の点でも PR にできる状態になったら、このゲートを 1 回実行します。

1. ミューテーションテストまたは代替エビデンス：意味がある場合は、蓄積されたブランチ／PR の対象範囲に対して mutation-testing を実行し、kill 数／survive 数／スコアのレポートを作成します。実行しない場合は、明示的な N/A の理由と、相応の到達可能性、設定、コントラクト、統合、または運用上のエビデンスを記録します。
2. 該当する場合はミュータントを kill：価値のある生存ミュータントに対して動作テストを追加または強化し、明らかな不足は直接修正します。生存ミュータントの価値が曖昧な場合は、人に確認します。
3. ゲート内で再実行：生存ミュータントに対処する間はフォーカスしたミューテーションテストを実行し、その後、ブランチ差分コマンドを再実行します。これらの再実行は同じ PR ゲートに含まれ、TDD の各変更でミューテーションテストを実施することにはなりません。
4. 検証：残りの PR チェックを完了し、すべてのテストが合格していることを確認します。ワークフローを満たすためだけに、構造上のミュータントを作り出さないでください。

---

エビデンス、履歴、カバレッジ

想定どおりの RED の失敗、GREEN の成功、最後に実行する非ウォッチの検証を記録し、最終回答で3つすべてを明記してください。RED の実行については、使用したセレクターと発生した失敗（例：pinNote is not a function）を記載し、GREEN の実行と、完了した非ウォッチの全テスト実行についても記載してください。成功した件数だけを報告しても、TDD のエビデンスを示したことにはなりません。既存のコミット履歴が手順の裏付けになる場合もありますが、TDD の体裁を整えるためだけにコミットを作り直してはいけません。リポジトリのデリバリーポリシーに従ってください。

カバレッジは診断情報であり、普遍的な目標ではありません。ポリシーで必要とされる場合、またはカバレッジについて主張する場合は、リポジトリのカバレッジコマンドを実行してください。主張する行、分岐、ステートメント、関数を正確に検証し、未カバーの箇所がテストされていない動作に当たるかどうかを確認してください。高い割合でもテストの品質が証明されるわけではありません。相応の範囲で、testing スキルのカバレッジの見せかけに関するチェックと、ミューテーションテストまたは代替エビデンスを活用してください。

---

開発ワークフロー

新機能の追加

1. リポジトリの開始手順を守る - 必須の場合は最初の編集前に実績のあるウォッチャーを起動し、それ以外の場合は RED の直後に起動します
2. 失敗するテストを書く - 期待する動作を記述します
3. 焦点を絞ったフィードバックを開始または確認する - リポジトリ管理のウォッチャーを優先します。それ以外の場合は、インストール済みバージョンと設定が標準のライブ検証に合格した後に限り、差分から対象を選択した Vitest ウォッチャーを使用するか、影響を受ける範囲に相当するワンショット実行を使用します。期待したテストが、想定した理由で失敗することを確認します
4. 最小限を実装する - 合格に必要な分だけ実装します
5. 焦点を絞ったテスト／影響を受けるテストを実行する - 動作と関連テストが合格することを確認します
6. 該当し、有益であればリファクタリングする - 焦点を絞ったテストと影響を受けるテストが引き続き合格する状態で、コード構造を改善します
7. RED-GREEN-REFACTOR を繰り返す - 計画した PR の範囲が完了するまで、ミューテーションテストのハーネスを実行せずに続けます
8. PR の準備ができた段階で、ミューテーションゲートを1回実行する - ウォッチャーを停止し、有意義な場合はミューテーションテストを実行します（そうでない場合は、明示的に N/A と記録し、相応の代替エビデンスを提示します）。ゲート内で有益な生き残りを解消し、リポジトリで定義された非ウォッチの PR チェックを完了します。対象リポジトリのエビデンス無効化ルールを適用してください。このディストリビューションの鮮度モデル（panel-review スキル、references/pr-readiness.md）を使うのは、より厳格なリポジトリルールがない場合に限ります

ワークフローの例

# 1. If the repository requires its watcher before the first edit, start it now:
# pnpm test:watch

# 2. Write failing test
it('should reject empty user names', () => {
  const result = createUser({ id: 'user-123', name: '' });
  expect(result.success).toBe(false);
}); # ❌ Test fails (no implementation)

# 3. If it is not already running, start the tested repository watcher now.
#    Starting after RED makes the expected initial execution easy to verify when
#    the repository does not mandate an earlier start.
pnpm test:watch
# If no repository watcher exists and this Vitest version/configuration has
# passed the live proof:
pnpm exec vitest --changed origin/main --watch
# Or use an affected one-shot:
pnpm exec vitest --changed origin/main --run

# 4. Confirm the expected RED test executed, then implement minimum code
if (user.name === '') {
  return { success: false, error: 'Name required' };
} # ✅ Test passes

# 5. Refactor if needed (extract validation, improve naming)

# 6. Repeat RED-GREEN-REFACTOR increments without running the mutation harness

# 7. After the final edit, stop the watcher with Ctrl+C. When the accumulated work
#    is otherwise ready to create the PR, run the
#    end-of-phase mutation gate once and address valuable survivors within it.

# 8. Exit watch mode and finish the remaining PR verification, including the
#    inspected repository-defined complete non-watch test gate.

#     If later verification changes mutation-relevant production or applicable
#     tests/evidence, apply the target repository's invalidation rule and rerun
#     the evidence it invalidates; use this distribution's review
#     pr-readiness freshness model only when no stricter rule exists. Keep
#     final-tree verification current.

---

プルリクエストの要件

PR を提出する前に：

• リポジトリで必須とされるすべてのテストが合格している
• リポジトリで必須とされるすべてのリンティングと型チェックが合格している
• カバレッジに関する主張とリポジトリのしきい値を、リポジトリ独自のコマンドで検証している
• 有意義な場合は、蓄積された PR の範囲に対するフェーズ終了時のミューテーションゲートを1回実行し、有益な生き残りを解消する。そうでない場合は、明示的に N/A と記載し、相応の代替エビデンスを提示する
• ミューテーションテストまたは代替エビデンスが対象リポジトリの無効化ルールを満たしている。全体的な再利用ガイダンスによって、より厳格なリポジトリポリシーが弱められていない
• ウォッチャーが停止しており、リポジトリで定義された非ウォッチの完全な PR テストゲートが合格している。モノレポの場合、設定済みのすべてのプロジェクトと必須の統合／E2E テストスイートが含まれている
• PR の範囲に一貫性があり、リポジトリのデリバリーポリシーに従っている
• 動作の説明を含める（実装の詳細ではなく）

PR の説明例：

## Summary

Adds support for user role-based permissions with configurable access levels.

## Behavior Changes

- Users can now have multiple roles with fine-grained permissions
- Permission check via `hasPermission(user, resource, action)`
- Default role assigned if not specified

## Test Evidence

✅ 42/42 tests passing
✅ Repository coverage gate passed (see attached report)

## TDD Evidence

RED: expected permission test failed before production changes
GREEN: focused permission tests passed after the minimum implementation
REFACTOR: affected tests remained green after permission resolution was simplified

---

リファクタリングの優先順位

GREEN によって動作テストのベースラインが合格した後、構成を変更するのが該当する場合は、改善の機会を評価し、分類してください。優先順位の分類表と詳細な方法については、refactoring スキルを読み込んでください。このガイダンスは同スキルが管理しています。ミューテーションテストは、フェーズ終了時の PR 準備ゲートで、蓄積された結果を後から検証します。

---

避けるべきアンチパターン

• ❌ 振る舞いテストが失敗していないのに、本番の動作を新規作成または変更する
• ❌ 振る舞いを変えないリファクタリングを正当化するために、実装の形に関する失敗テストをでっち上げる
• ❌ 実装の詳細をテストする（内部メソッドに対するスパイなど）
• ❌ 反射的に、すべての実装ファイルに対応するテストファイルを作る
• ❌ 信頼できる分離とクリーンアップを行わずに、変更可能なテスト状態やライフサイクルフックを共有する
• ❌ 検証せずにカバレッジの主張を信じる
• ❌ テスト対象の関数をモックする
• ❌ 本番コードが管理するコントラクトスキーマをテストファイル内で重複させる
• ❌ シナリオに必要な要素が揃っていないオブジェクトをファクトリーが暗黙的に返す。意図的に無効なフィクスチャは、名前と型で明示する
• ❌ 推測に基づくコード（テストのない「念のため」のロジック）
• ❌ フォーカスしたテストのウォッチや関連テスト・影響を受けるテストの選択を使わず、編集のたびにテストスイート全体を再実行する
• ❌ ランナーが変更セット全体から影響を受けるテストをすべて特定できるのに、GREEN／REFACTOR でテストファイルを1つだけ手動で選ぶ
• ❌ ウォッチャーの起動時にテストファイルの一覧を固定し、新たに作成されたテストがループに加わらないようにする
• ❌ 収集されたテストがゼロ件であることや --passWithNoTests を、RED／GREEN の証拠として扱う
• ❌ ウォッチモードの結果を、PR 前の完了済みテストスイート全体のゲートとして扱う
• ❌ --changed --watch が保存のたびに VCS の影響範囲を再計算すると想定したり、後続の再実行が初回の VCS 選択実行で実行されたテストに限定されると想定したりする
• ❌ ループ、タイムアウト、または引き継ぎの後も、ウォッチャーやその子プロセスを実行したままにする
• ❌ CI、フック、または別の有限コマンドから、範囲が限定されクリーンアップが実証されたライブプルーフ用ハーネス内を除き、ウォッチモードを呼び出す

テストに関する詳しいアンチパターンについては、testing スキルを読み込んでください。

---

確認用チェックリスト

作業を完了とする前に、次を確認してください。

• 新規または変更したすべての振る舞いに、それを必要とする失敗した振る舞いテストがある。または、変更が振る舞いを変えない REFACTOR の一部分であることを明示的な証拠で示している
• RED、GREEN、最終検証の証拠を記録している。コミット履歴は、リポジトリでそのように扱われている場合に限り補足的な証拠となる
• 内側のループ中、フォーカスしたテストと影響を受けるテストがすべて成功している
• RED／GREEN の結果を主張する場合、実際に収集され実行された期待どおりのテストをそれぞれ明記している
• ウォッチャーを停止し、ウォッチャーのプロセスや一時フィクスチャを残していない
• PR 前に、ウォッチモードではないテストスイート全体の実行が完了し、成功している
• カバレッジの主張やリポジトリのしきい値は、リポジトリ管理のコマンドで検証している
• 最終返信で、ミューテーションゲートの結果を明記している。蓄積した範囲に対して1回実行し、価値のある生存ミュータントに対処したこと、N/A と妥当な代替証拠を明示したこと、またはこのスライスがまだ PR の準備段階に達していないため PR ゲートまで明示的に延期したことのいずれかを示す。記載漏れは禁止
• テスト状態が分離されている。明確さが向上する場合はフィクスチャやファクトリーを使用している
• テストで実装の詳細ではなく、振る舞いを検証している
• 適用可能な場合はリファクタリングを評価し、価値があれば適用している。そうでない場合は N/A と明記している