Integration Testing は AI が代わりにスキップできない部分だ

プラットフォームが動く。End-to-end、最後まで全部:log in、lobby を見て回る、テーブルに座る、座席を見る、buy-in ダイアログを開く、ハンドを観察する。

ここまで来るのに 4 本の記事がかかった。ルーティングのバグ、データフォーマットの不一致、壊れた auth guard、コード変更を黙って無視する開発環境。

Integration testing もかかった。この記事のテーマだ。

テスティングフェーズはどう見えたか

Playwright を使ってテストした — 実際のブラウザインタラクションをスクリプト化し、結果を検証するブラウザ自動化ツールだ。実際のブラウザ。実際のリクエスト。実際にレンダーされた UI。

セッション:テスト用の認証情報で log in、lobby に到達、テーブルの card が正しい高さでレンダーされることを確認、テーブルへナビゲート、ヘッダーバーに lobby ボタンと help ボタンが現れることを確認、seat picker が空いている全席をレンダーすることを確認。

最初の実行ですべてのステップが失敗した。

Table card が高さ 572 ピクセルだったのは、CSS Grid が行にアイテムが 1 つしかないとき、デフォルトで align-items: stretch を適用するからだ。誰もこれを指定していない。誰も意図的に壊していない。CSS がただそうするだけだ。

テーブルへのナビゲーションがブラウザを redirect ループに送り込んだ。Auth guard が決して値が入らない router context の値をチェックしていた。

これらは AI 特有の失敗モードではない。スタック全体が一緒に動いたときだけ現れるバグの類だ。人間が書いたコードでも同じように現れただろう。テスティングフェーズはどちらにせよこれを捕まえる。

なぜ AI 生成のコードでもこれが必要か

テスティングをオプションとして扱う AI 支援開発のバージョンがある。論理:spec は正しい、エージェントは spec を実装する、ゆえに実装は正しい。

この論理は統合レイヤーで失敗する。

個々のコンポーネントはそれぞれの spec を正しく実装しても、互いにコミュニケーションするのに失敗することがある。Spec は孤立した動作を記述する。Integration testing は組み合わさった動作を検証する。システムのすべての領域をカバーする 100 ページの仕様も、すべての CSS Grid デフォルトとすべての router context 初期化順序を記述するわけではない。

そのものを動かすことが、そのものが動いている様子を見る唯一の方法だ。

人間が今もやること

テストセッションでのすべての失敗は、ブラウザを見ている人が特定した。Lobby card が全高に伸びる — その観察は視覚的で、ログには出ない。テーブルが空白でロードされる — それは network request を見て 404 に気づく必要があった。Redirect ループはブラウザのナビゲーション履歴をたどって追跡された。

これらの観察は、AI が診断に関わる前に起きる。エージェントはあなたが記述したバグを追跡できる。記述には、動作がどう見えるべきかを理解している人間が必要だ。

これは方法論の限界ではない。方法論が正しく機能している姿だ。人間がシステムを定義し、出力を検証し、失敗をエスカレートする。エージェントが診断し修正する。この分業はテスティングフェーズを通じて成り立つ。

今どこにいるか

Dev 環境は end-to-end testing をパスする。プラットフォームは運用上の準備ができている。今から open beta までの間:staging での最終検証、card payment processor の統合、geofencing のエンフォース。

テスティングフェーズは終わっていない。スタックの上の方へ移動しただけだ。

salty.poker チェンジログ は ship するたびに更新される。リアルタイムで build を追いたいならそれを見るといい。

エンジニアリング方法論についてのフルシリーズ — spec がどうセッションを動かすか、アーキテクトの役割がテスティングフェーズを通してどう見えるか、そしてほぼ 30 年のソフトウェア構築がイテレーションについて何を教えるか — そのシリーズは The Salty Korean で並行して進行している。

Stay salty.