qa-game

QA ゲーム

既存のゲームプロジェクトに Playwright による自動 QA テストを追加します。テストでは、ゲームが起動すること、シーンが動作すること、スコア機能が機能すること、ビジュアルが壊れていないことを確認します。ゲームを守るセーフティネットのようなものです。

手順

$ARGUMENTS に指定されたゲーム（パスが指定されていない場合は現在のディレクトリ）を分析します。

まず、game-qa スキルを読み込み、テストパターンとフィクスチャをすべて確認します。

Step 1: テスト可能性の監査

• package.json を読み、エンジンと開発サーバーのポートを特定します
• vite.config.js を読み、サーバーのポートを確認します
• src/main.js を読み、window.__GAME__、window.__GAME_STATE__、window.__EVENT_BUS__ が公開されているか確認します
• src/core/GameState.js を読み、利用できる状態を把握します
• src/core/EventBus.js を読み、どのイベントがあるか把握します
• src/core/Constants.js を読み、ゲームのパラメーター（レート、速度、時間、最大値）を把握します
• すべてのシーンファイルを読み、ゲームの流れを把握します
• design-brief.md があれば読みます。想定されるメカニクス、値の規模、勝敗の到達可能性が記載されています

Step 2: Playwright のセットアップ

1. 依存関係をインストールします：npm install -D @playwright/test @axe-core/playwright && npx playwright install chromium
2. 正しい開発サーバーのポートと webServer 設定を含む playwright.config.js を作成します
3. src/main.js に window.__GAME__、window.__GAME_STATE__、window.__EVENT_BUS__、window.__EVENTS__ がまだ公開されていなければ追加します
4. テストディレクトリ構成を作成します：

   tests/
   ├── e2e/
   │   ├── game.spec.js
   │   ├── visual.spec.js
   │   └── perf.spec.js
   ├── fixtures/
   │   └── game-test.js
   └── helpers/
       └── seed-random.js
   

5. npm スクリプトを追加します：test、test:ui、test:headed、test:update-snapshots

Step 3: テストの作成

ゲームの実際の動作に基づいてテストを作成します。

• game.spec.js：起動テスト、シーン遷移、入力処理、スコア、ゲームオーバー、再開
• visual.spec.js：安定したシーン（ゲームプレイの初期状態、ゲームオーバー）のスクリーンショット回帰テスト。動くオブジェクトで不安定になるため、プレイ中のスクリーンショットは対象外にします。
• perf.spec.js：読み込み時間の上限、ゲームプレイ中の FPS、キャンバスの寸法

game-qa スキルのパターンに従います。gamePage フィクスチャを使用します。ゲームの状態を読み取るには page.evaluate() を使用します。入力には page.keyboard.press() を使用します。

Step 4: デザイン意図テスト

game.spec.js に test.describe('Design Intent') ブロックを追加します。これらのテストでは、実装はされていても影響が弱すぎるメカニクスを検出します。

1. 敗北条件：ゲームに敗北状態があるかどうかを確実に判定します。 GameState.js を読みます。won、result、または同様のブール値／列挙値フィールドがあれば、ゲームは勝利と敗北を区別します。また、main.js の render_game_to_text() も確認します。別個の結果モード（例：'win' と 'game_over'）を返す場合、ゲームには敗北状態があります。

   敗北状態がある場合：ゲームを開始し、入力を一切せず、最後まで進めます （Constants.js のラウンド時間を使い、page.waitForFunction を使用します）。結果が敗北であることをアサートします（例：won === false、 mode === 'game_over'）。

   このアサーションは必須です。 何もせずにプレイヤーが勝つ場合にテストが成功するような記述はしないでください。現在のゲームの動作が「入力なしでプレイヤーが勝つ」なら、それはバグです。これを検出するテストを作成してください。

2. 対戦相手／AI の圧力：AI によって駆動されるメカニクス（自動で上昇するバー、敵の出現、難易度上昇）がある場合、十分な状態変化が発生することをテストします。プレイヤー入力なしでゲームを半分の時間だけ進めます。対戦相手の状態が最大値の少なくとも 25% に達することをアサートします。design-brief.md がある場合は、しきい値に記載された想定値を使用します。それ以外の場合は、Constants.js から導きます。rate * duration を計算し、意味のあるレベルに達することをアサートします。

3. 勝利条件：プレイヤーが積極的に入力すると勝利できることをテストします。ラウンドを通して素早く入力し、結果が勝利であることをアサートします。

Step 5: エンティティの相互作用を監査する

初めてプレイする人が混乱するような、衝突や相互作用の非対称性がないか監査します。

design-brief.md に「Entity Interactions」セクションがある場合は、それをチェックリストとして使用します。ない場合は、GameScene.js を直接監査します。

1. すべての衝突ハンドラー、オーバーラップチェック、距離ベースの相互作用を見つけます
2. どのエンティティがどのエンティティと相互作用するかを整理します
3. 画面上で動くエンティティが、片方（プレイヤーまたは対戦相手）とだけ相互作用し、もう片方とは相互作用しない場合は、テストファイルにエンティティ名と非対称性を記した // QA FLAG: asymmetric interaction コメントを追加します

これはフラグであり、致命的なエラーではありません。意図的な非対称性もあります（例：プレイヤーにだけ影響するハザード）。このフラグにより、その非対称性が見落としではなく、意識的な設計上の選択であることを確認できます。

Step 6: 実行して検証する

1. npx playwright test を実行して、すべてのテストを実行します
2. 初回実行でビジュアルテストが失敗した場合、それは想定どおりです。npx playwright test --update-snapshots でベースラインを生成します
3. もう一度実行して、すべてのテストがパスすることを確認します
4. 結果を要約します

Step 7: 報告する

ユーザーに平易な英語で伝えます。

• 作成したテストの数と、そのテストで確認する内容
• 実行方法：npm test（ヘッドレス）、npm run test:headed（ブラウザーを表示）、npm run test:ui（インタラクティブなダッシュボード）
• 「これらのテストは安全網です。変更を加えた後に実行して、何も壊れていないことを確認してください。」

使用例

/qa-game examples/flappy-bird

結果：Playwright をインストール → 15 個のテストを作成（起動、シーン遷移、入力、スコア、再起動、ゲームオーバー、ビジュアルリグレッション、FPS、読み込み時間） → フィクスチャーとヘルパーを含む tests/ ディレクトリを生成 → すべてのテストがパス。変更後はいつでも npm test を実行できます。

次のステップ

ユーザーに伝えます。

ゲームに自動テストが追加されました！最後に、/game-creator:review-game を実行して、アーキテクチャを全面的にレビューしてください。コード構造やパフォーマンスのパターンをチェックし、具体的な改善案とともにスコアを提示します。

パイプラインの進捗： /viral-game → /design-game → /add-audio → /qa-game → /review-game

(これは /viral-game の一括実行パイプラインであり、複数セッションで進めるマイルストーン方式のワークフロー /make-game ではありません。)