AIウェブ開発テスト:ループのもう半分である検証

AIウェブ開発テストが見るべきところ

いずれも差分には現れません。レビューを速くしても効かないのはそのためです。一方で、動いているアプリを30秒触れば見えてきます。だからこそ、確認はそこで行う必要があります。

エージェントが書いたテストでループが閉じない理由

実装と一緒に生成されたテストは、その実装の前提を共有します。あるエンドポイントが404ではなく空の配列を返すとコードが思い込んでいれば、テストも同じ思い込みを検証して成功します。手に入るのはカバレッジだけで、独立したシグナルは得られません。

ループを閉じる確認は、コードが自分自身について抱いている理解ではなく、意図された挙動に照らして、デプロイ済みのプロダクトを実際に動かすものでなければなりません。

実際に使える速さを保つ

機能を作るより時間のかかる検証ステップはスキップされますし、それは正しい判断です。釣り合いを保つポイントは3つあります。画面ではなくフローを対象にすること、チェーンを短く保つこと、そして保存のたびではなくプルリクエストで実行することです。

実際に回せるだけループを締める

遅いと感じる検証ステップはスキップされます。しかもそのスキップには合理性があるので、テンポはカバレッジと同じくらい重要です。

釣り合いを保つポイントは3つあります。1つ目は、画面ではなくフローを対象にすること。フローなら確認は1回で済みますが、画面単位では5回になります。2つ目は、各フローを、実際の不具合を捉えられる最短の経路にとどめること。多くの場合、10ステップではなく3〜4ステップです。3つ目は、広めのスイートはプルリクエストで実行しつつ、1つか2つの確認は作業中にも回せる速さに保つことです。

見落とされがちなのは、この最後の使い分けです。作りながら回す確認と、マージを守る確認は役割が違います。1つのスイートで両方を賄おうとすると、頻繁に回すには遅すぎるか、信頼するには薄すぎるかのどちらかになります。

ループに組み込む

セットアップでは、検証用のスキルをコーディングエージェントに組み込みます。そのため確認は、別立ての雑務ではなく、作業をしている場所でそのまま行われます。

何もインストールしたくない場合は、ダッシュボードでも同じことができます。コマンドラインで行えるそのほかの操作がすべてまとまっているのが、 CLI リポジトリ。

• GitHub App は、TestSprite のダッシュボードで設定する Webhook です。パイプラインがすでに発行しているデプロイイベントを受け取るため、リポジトリ側は何も変わりません。

• GitHub Actions は、このステップを自分のワークフローの中に置く方法で、設定はターミナルから行います。

エージェントには検証できないものを TestSprite が検証する

デプロイ済みのアプリケーションを、コードが前提としている内容ではなく、こうあるべきだと指定した挙動に照らして検証します。この独立性こそが要点です。実装の隣で書かれたテストは実装の前提を共有するため、両方が間違っている箇所まで含めて、実装と一致してしまいます。

セットアップでは、検証用のスキルをお使いのコーディングエージェントに組み込みます。そのため確認は、変更を加える作業の一部として実行されます。手順はセレクターではなく意図として記述され、失敗はエージェントがそのまま対処できる1つのまとまりとして返ってきます。これによって、修正が変更と同じループの中にとどまります。

得られるのは、状態・タイミング・2人目のユーザーに起因する不具合を、ユーザーに見つけられる前に、マージ前の段階で捕まえられることです。しかも、機能の実装より時間のかかる検証ステップを抱え込むことはありません。