testing

ソフトウェアのテスト

まず検証ループを回す

変更を完了とする前に、必ず実行可能なチェックを用意します。新しいロジックならレッドからグリーンへ、バグ修正なら失敗してから成功する回帰テストを用意し、それ以外は既存のテストスイートを実行します。チェックなしに変更をリリースしてはいけません。

レッド、グリーン、観察。レッド、グリーン、思い込みではありません：「失敗を確認する」（以下の回帰ワークフロー項目と、TDD の「失敗するのを見る」ステップ）は、修正や実装に着手する前に、実際にテストを実行し、失敗時の出力を読むことを意味します。「これは失敗するはずだ」と考えて実行を省略してはいけません。

反証可能な完了条件：機能の実装を書く前に、完了を定義する具体的で検証可能な条件を 1 つ明示します。「これで動くはず」ではなく、テストやコマンドで確認または反証できる条件にします。

説明より証拠を：完了の主張は、提示する証拠の質に左右されます。テスト実行結果の貼り付け、実際の終了コード、プッシュ済みのコミット SHA などが証拠になります。コードがどのように動作するはずかを説明しても証拠にはなりません。チェックを再実行し、その出力を引用してください。

MCP ツール

Chrome DevTools（E2E テスト）：

• 実際のブラウザーでユーザーフローを自動化します
• ビジュアルリグレッション用のスクリーンショットをキャプチャします
• アクセシビリティテストに Lighthouse を実行します
• テスト実行中のパフォーマンスをプロファイリングします

ワークフロー

• 分析：Glob と Grep を使って、テストされていないコードを特定します
• 単体テスト：すべての公開関数を網羅します
• エッジケース：境界値とエラー条件をテストします
• 統合テスト：外部依存関係をテストします
• E2E：Chrome DevTools を使ってブラウザー操作を自動化します
• 回帰テスト：バグを再現するテストを追加し、現在のコードで失敗することを確認してから修正します。修正後もテストが成功する状態を保ち、以降もテストスイートに残してください（削除したり、スキップしたりしてはいけません）

テスト駆動開発

新しいロジックを書くときは、レッド、グリーン、リファクタリングを基本とします。

1. レッド：実装を書く前に、1 つの振る舞いに対する失敗するテストを書きます。
2. グリーン：テストを成功させるために必要な最小限のコードを書きます。
3. リファクタリング：テストスイートがグリーンの間に限り、構造を整理します。このステップでは新しい振る舞いを追加しません。

• 1 つのテストにつき 1 つの振る舞いをテストします。説明に「そして」が必要なら、テストを分割してください。
• スパイクや使い捨ての調査を除き、失敗するテストを根拠とせずに本番コードを書いてはいけません（マージ前にテストを削除するか、後から補ってください）。
• 同じコミットでリファクタリングと振る舞いの追加を行ってはいけません。作業の帽子を切り替える前に、グリーンの状態でコミットしてください（code-quality.md の 2 つの帽子ルールを参照）。

TDD が適切な基本方針となる場合：新しいビジネスロジック、バグ修正（まず回帰テストを書いて失敗するのを確認し、その後で修正します）、明確な入出力の契約があるコードです。

TDD が適切でない場合：探索的なスパイク、使い捨てスクリプト、UI のレイアウトやスタイルの調整、生成されたボイラープレートです。これらは形が固まってからテストを書きます。

テスト品質基準

決定性

テストは毎回同じ結果にならなければなりません。実時間、ランダム値、制御されていない外部状態に依存してはいけません。

独立性

テストは互いに依存せず、可変状態を共有してはいけません。

明確さ

テスト名には、関数名だけでなく、テスト対象の振る舞いを記述します。