記事一覧
·5 分·GXAI Studio

Step 6 — テスト

リリース前、自動テストがロボットのようにゲームをプレイ。失敗なら deploy ブロック。

プロセステスト

テストなしのコードは推測。

リリース前、自動プレイスルー を走らせる — ロボットがゲームをプレイし、Step 3 のプランと結果を照合する。

1 つでも失敗したら出さない。直してから。

ロボットの仕事

tests-running
tap-bounce-survives-spike PASS no-input-loses-energy PASS combo-resets-on-late-tap PASS boss-wall-defeats-ball FAIL ✗

期待:壁で跳ね返る 実際:壁を通り抜ける

✗ 1 個失敗 → deploy ブロック

/テスト

ロボットがプレイする。

本物のタップ。本物の物理。本物のスコア。人は見ていない。

各テストはプランの 1 ルールにマップ。ルール #6 失敗 = どこが壊れたか即座にわかる。

なぜ AI に自己採点させないか

最重要ルール。

AI がコードを書くのを手伝った。そして 別のシステム がテストを走らせる。AI は「テスト合格」を判断しない。コンピュータが実際の出力と期待値を比較。純粋な数字。

how-grading-works
# プランは言う: 完璧 5 タップでコンボ = 5

# ロボットが完璧 5 タップ。 # 画面のコンボ数を読む。

実際:5 期待:5

✓ 一致 → PASS

# もし 4 だったら: 実際:4 期待:5

✗ 不一致 → FAIL 「合ってそう」は許されない。

/no-vibes

数字は嘘をつかない。

チェックは「正しく見える」じゃなく「5 == 5」。数字が一致しなければ失敗。

これが vibe-coded アプリのバグが私たちのゲームに乗らない理由。

落とし穴

✗ AI に自己採点させる(vibes scoring)
✗ 「私の Mac で速いから」性能テストスキップ
✗ ハッピーパスのみテスト
✗ 失敗テストを直さず無効化
✗ flaky テストを「たまに」扱い — それは本物のバグ

← Step 5 — コード · Step 7 — ローンチ →

共有:
ブログ