acceptance-testing

受け入れテスト

概要

受け入れ基準に基づくバックプレッシャーでは、仕様の受け入れ基準をテスト要件に直接結び付け、完了を早まって主張できない検証チェーンを構築します。このシステムでは不正はできません。仕様の受け入れ基準から導き出されたテストに合格しない限り、機能が完成したとは主張できません。

開始時に宣言します：「仕様の基準に照らして検証するため、受け入れテストのスキルを使用します。」

---

バックプレッシャーチェーン

+------------+     derives      +------------+     validates    +------------+
|   SPECS    |---------------->|   TESTS    |---------------->|   CODE     |
|            |                  |            |                  |            |
| Acceptance |                  | Test cases |                  | Must pass  |
| Criteria   |                  | from AC    |                  | all tests  |
+------------+                  +------------+                  +------------+
      ^                                                              |
      |                    backpressure                               |
      +--------------------------------------------------------------+
      If tests fail, implementation must change (not the spec or test)

---

フェーズ 1：受け入れ基準の抽出

目標： 各仕様ファイルから、すべての Given／When／Then 形式の受け入れ基準を抽出します。

実施内容

1. すべての仕様ファイル（specs/*.md）を見つけます
2. ID とともに、すべての受け入れ基準を抽出します
3. 構造化された形式で記録します

抽出例

## From spec: 01-color-extraction.md

### AC-1: Extract dominant colors
- Given an uploaded image (PNG, JPG, or WebP)
- When color extraction is triggered
- Then 5-10 dominant colors are returned
- And each color includes hex, RGB, and HSL representations

### AC-2: Handle invalid images
- Given a corrupted or unsupported file
- When color extraction is attempted
- Then an appropriate error is returned
- And no partial results are produced

停止 — 厳格なゲート：以下を満たすまでフェーズ 2 に進まないでください：

• すべての仕様ファイルを見つけて読みました
• すべての受け入れ基準を ID とともに抽出しました
• 基準が Given／When／Then 形式になっています
• 曖昧な基準がありません（曖昧な場合は、仕様作成者に確認してください）

---

フェーズ 2：テストケースの導出

目標： すべての受け入れ基準を、少なくとも 1 つのテストケースに対応付けます。

┌─────────────────────────────────────────────────────────────────┐
│  HARD-GATE: Every acceptance criterion must have at least one   │
│  corresponding test. No exceptions. If a criterion has no       │
│  test, the feature is NOT complete.                             │
└─────────────────────────────────────────────────────────────────┘

トレーサビリティテーブル

受け入れ基準	テストの種類	テストの説明	テストファイル：行
AC-1：主要な色を抽出する	統合テスト	有効な画像をアップロードし、5～10 色が HEX／RGB／HSL 形式で返されることを確認する	test/color.test.js:15
AC-2：無効な画像を処理する	統合テスト	破損したファイルをアップロードし、エラーが発生することと部分データが残らないことを確認する	test/color.test.js:42

判断表：受け入れ基準に対するテストの種類

基準の種類	テストの種類	理由
データの入出力動作	統合テスト	実際のデータフローをテストするため
エラー処理の動作	統合テスト	エラーパスをエンドツーエンドでテストするため
パフォーマンス要件	負荷テスト	負荷時の測定が必要なため
UI の動作	E2E（Playwright）	実際のブラウザー操作をテストするため
主観的な品質	LLM-as-judge	決定論的にテストできないため
セキュリティ要件	統合テスト＋セキュリティテスト	認可と入力検証をテストするため

停止 — 厳格なゲート：以下を満たすまでフェーズ 3 に進まないでください：

• すべての受け入れ基準に、少なくとも 1 つのテストが対応付けられています
• テストの種類が基準の種類に適しています
• テストファイルの場所が特定されています

---

フェーズ 3：実装前にテストを作成する

目標： 機能が正しく実装されるまで失敗する受け入れテストを作成します。

実施内容

このフェーズは test-driven-development と連携します：

1. 受け入れ基準からテストを作成する（RED）
2. テストに合格するよう機能を実装する（GREEN）
3. テストを成功状態に保ちながらリファクタリングする（REFACTOR）

振る舞いの結果に注目する

これを検証する（振る舞い）	こちらは検証しない（実装）
「5～10 色が返される」	「k=8 で K-means を実行する」
「応答時間が 200ms 未満である」	「2 回目の呼び出しでキャッシュがヒットする」
「エラーメッセージがユーザーにわかりやすい」	「CustomError クラスがスローされる」
「セッションをまたいでデータが保持される」	「PostgreSQL INSERT が実行される」
「UI が 500ms 以内に更新される」	「WebSocket メッセージが受信される」

停止 — 厳格なゲート：以下を満たすまでフェーズ 4 に進まないでください：

• すべての受け入れテストを作成しました
• 実装前にテストが失敗することを確認しました（RED を確認済み）
• テストが実装の詳細ではなく、振る舞いの結果を検証しています

---

フェーズ 4：検証ゲート

目標： タスクの完了を主張する前に、すべてのゲートに合格する必要があります。

ゲート	確認内容	ツール	必須
単体テスト	すべて合格	テストランナー	常に
統合テスト	すべて合格	テストランナー	常に
受け入れテスト	受け入れ基準から導出されたテストがすべて合格	テストランナー	常に
ビルド	エラーなくコンパイルできる	ビルドツール	常に
リント	違反がない	リンター	常に
型チェック	型エラーがない	型チェッカー	該当する場合

┌─────────────────────────────────────────────────────────────────┐
│  HARD-GATE: ACCEPTANCE                                         │
│                                                                 │
│  Cannot claim completion without ALL acceptance tests passing.  │
│  If any acceptance test fails, the feature is NOT done.        │
│  Fix the implementation, not the spec or the test.             │
└─────────────────────────────────────────────────────────────────┘

停止 — ハードゲート：以下を満たすまでフェーズ 5 に進まないでください：

• すべての検証ゲートに合格している
• 受け入れテストが合格し、ステータスがグリーンになっている
• ゲートをスキップしたり、「後で修正する」と記録したりしていない

---

フェーズ 5：トレーサビリティレポート

目標： すべての仕様基準をテストと結果に結び付けるレポートを作成します。

レポートテンプレート

## Acceptance Test Report

| Spec | Criterion | Test | Status |
|------|-----------|------|--------|
| 01-color-extraction.md | AC-1: Extract dominant colors | test/color.test.js:15 | PASS |
| 01-color-extraction.md | AC-2: Handle invalid images | test/color.test.js:42 | PASS |
| 02-palette-rendering.md | AC-1: Render palette grid | test/palette.test.js:8 | PASS |

### Summary
- Total criteria: N
- Tested: N
- Passing: N
- Failing: 0
- Coverage: 100%

---

アンチパターン／よくある間違い

アンチパターン	問題となる理由	正しいアプローチ
実装に合わせて仕様を変更する	仕様の目的を損ないます	仕様ではなく実装を修正します
エッジケースの基準を省略する	エッジケースは本番環境のバグにつながります	すべての受け入れ基準にテストを用意します
実装の詳細をテストする	リファクタリングで壊れる脆弱なテストになります	観測可能な動作の結果をテストします
受け入れテストなしで「テストに合格した」と主張する	単体テストだけでは不十分です	受け入れテストは別途必須のカテゴリです
実装後に受け入れテストを書く	仕様を定めるのではなく、合格するようにテストが作られてしまいます	実装前に書きます（TDD）
受け入れテストを「後で」に先送りする	後で、という時は来ません	コーディング前のフェーズ 2 で書きます
失敗したテストを「既知の問題」として記録する	不完全な実装を隠してしまいます	テストに合格するまでコードを修正します

---

合理化の防止

言い訳	実態
「単体テストでカバーしています」	単体テストはコンポーネントを個別にテストしますが、受け入れテストは統合された動作を検証します
「仕様は明らかなので、正式なテストは不要です」	明らかな仕様にも、検証可能なテストが必要です
「手動で確認できます」	手動での検証は再現性も信頼性もありません
「受け入れ基準が曖昧すぎてテストできません」	基準を明確にしてください。曖昧な仕様からは曖昧なコードが生まれます
「これは単なる見た目の変更です」	見た目の変更でも、レイアウト、アクセシビリティ、UX が損なわれることがあります

---

統合ポイント

スキル	関係
spec-writing	受け入れ基準は仕様に基づきます
test-driven-development	TDD サイクルでは、受け入れ基準から導かれたテストを使用します
llm-as-judge	決定論的にテストできない主観的な基準に使用します
verification-before-completion	最終検証では受け入れテストの確認を含めます
autonomous-loop	終了ゲートには、受け入れテストの合格が求められます
code-review	レビューでは受け入れテストの網羅性を確認します
planning	計画には受け入れテストの作成を明示的なタスクとして含めます

---

スキルの種類

RIGID — バックプレッシャーの連鎖を回避してはなりません。すべての受け入れ基準にテストが必要です。受け入れテストに合格しない限り、完了とは見なせません。仕様やテストではなく、実装を修正してください。