既存プロジェクトから自動テストを生成するには？
Zheshi Du
ほとんどのプロジェクトは、やがて同じ局面を迎えます。
プロダクトはリリース済みです。ユーザーは活発に利用しています。コードベースは、誰か一人がすべてを把握できる規模を超えて成長しています。そしていつの間にか、チームはテストの作成を省略してきました。怠慢ではなく、常にリリースすべきより緊急なものがあったからです。
今、そのトレードオフのコストが、誰かがコードに触れるたびに現れます。ある箇所の変更が、別の予期しない箇所を壊します。何をリファクタリングしても安全か、誰も確信が持てません。すべてのデプロイがリスクに感じられます。
解決策は、既存のものから自動テストを生成することです。問題は、完成する前に時代遅れになるテストファイルの作成に何週間も費やさずに、それを実現する方法です。
コードを読んでテストを生成する際の問題点
明白なアプローチは、ツールをコードベースに向け、そこから見つかったものを基にテストを生成させることです。
コードレイヤーのテスト生成は、ソースファイルを読み取り、関数シグネチャやコンポーネント構造をトレースし、現在の実装に対してアサートするテストスクリプトを生成します。高速です。カバレッジ数値も出ます。そして、実際の環境に対してスイートを実行した最初の瞬間に現れる根本的な問題があります。
コード検査から生成されたテストは、コードが今日何をするかについてのアサーションです。プロダクトが何をすべきかについてのアサーションではありません。既存のコードにバグがある場合（すべての既存プロジェクトにはあります）、それらのバグは期待される動作としてエンコードされます。生成されたテストはパスします。バグは残ります。
2つ目の問題があります。コード検査から生成されたテストスイートは、特定の瞬間の実装のスナップショットです。プロダクトが変更された瞬間（AIコーディングツールを使用するチームでは、テストが生成されたその日に変更されます）、テストは劣化し始めます。セレクタが壊れます。更新された戻り値に対してアサーションが失敗します。メンテナンスの負担がすぐに始まります。
実際に役立つテストを生成するには、異なる出発点が必要です。コードではなく、プロダクトです。
コードが言っていることではなく、プロダクトが行っていることから始める
既存プロジェクトからテストを生成する正しい方法は、実行中のアプリケーションから始め、実際の動作を探索し、その観測された動作に基づいたテストスイートを構築することです。
これは、テストカバレッジがないプロジェクトに参加したQAエンジニアが行うことです。彼らはまずソースファイルを読みません。アプリケーションを開き、見つけられるすべての機能をウォークスルーし、それぞれが何をすべきかを記録し、それらの観察からテストケースを構築し始めます。
彼らがテストするのはコードではなく、プロダクトです。生成されるテストはプロダクトの動作に基づいています。ユーザーにとってのプロダクトの振る舞いを変えないリファクタリングであれば、テストはそのまま機能し続けます。なぜなら、テストは実装の詳細ではなく、ユーザーが観察できる結果を記述しているからです。
TestSprite はこのプロセスをそのまま自動化します。
TestSprite が既存プロジェクトを探索する仕組み
TestSprite を既存プロジェクトに向けると、コードベースからではなく、起動中のアプリケーションから処理を開始します。
Claude Code、Cursor、Windsurf、またはその他の MCP 互換 AI IDE に組み込まれた TestSprite MCP Server を通じて、たった一つの指示で探索プロセス全体が開始されます。
"Help me test this project with TestSprite."
並列探索エージェントの集団がライブアプリケーションを訪問し、実際のユーザーと同じようにナビゲートします。探索可能なすべての機能を巡り、UI フローをクリックし、フォームやモーダル、ナビゲーションを操作しながら、プロダクトが実際に何をするのかを構造化されたマップとして構築します。
他の検証ツールはコードを読んで推測します。TestSpriteはアプリを開いて実際に使用します。
エージェントはアサートすべき関数を探しているのではありません。検証すべきユーザージャーニーを探しています。探索フェーズの出力は、プロダクトの実際の動作を構造化したモデルです。ユーザーが何をできるか、どのパスをたどるか、どのような結果に到達すべきか。このモデルがテスト生成の基盤となります。
PRD や仕様書が存在する場合、TestSprite はそれを解析してテストの目標をプロダクトの意図に紐付けます。存在しない場合、MCP サーバーはコードベース自体から意図をリバースエンジニアリングし、ルート定義、API コントラクト、コンポーネント構造を、プロダクトが何を実現するために構築されたかを示す証拠として扱います。いずれの場合も、生成されるテストは現在の実装がたまたま生成するものではなく、プロダクトが本来すべきことに基づいています。
生成されるものとその耐久性の理由
TestSprite が既存プロジェクトから生成するテストは、探索エージェントが発見した機能の全体をカバーします。
フロントエンドのフローは、ユーザーの操作と期待される結果を記述するテストケースでカバーされます。エージェントはチェックアウトフローをナビゲートし、各ステップを観察して、そのステップを実行し各ポイントで結果を検証するテストを生成します。エージェントは複数ステップのオンボーディングウィザードを見つけ、そのパスをトレースして、ハッピーパスと探索中に発見したエッジケースをカバーするテストを生成します。
バックエンド API は Backend Testing 2.0 によってカバーされます。API テストを生成する前に、エージェントはエンドポイントを呼び出して実際のレスポンスを観察します。実際のステータスコード、実際のフィールド名、実際のレスポンス形状です。アサーションはその観察に基づいています。CRUD ライフサイクルテストは実際の作成レスポンスから実際の ID をキャプチャし、自動的に後続ステップに渡します。完全なライフサイクルが初回から最後まで実行されます。
これらのテストが長期にわたって機能し続けるのは、実装ではなく動作に紐付けられているからです。ユーザーが何をして何を見るべきかを記述したテストは、コードがその結果を生成する方法を変えるリファクタリングでも生き残ります。特定の関数の戻り値に対してアサーションを設定したテストはそうではありません。
ローカル環境なしでの実行
既存プロジェクトからテストを生成する際の実際的な障壁の一つが環境のセットアップです。正式なテストインフラを持ったことがないチームは、多くの場合テスト環境もセットアップしていません。テストスイートをローカルで実行するには、データベースの状態、外部サービスの依存関係、認証設定、そしてドキュメント化されているかどうかわからない環境変数に対処する必要があります。
TestSprite はエフェメラルなクラウドサンドボックスによってこれを解決します。テストは数秒で立ち上がるセキュアで隔離された環境で実行され、スイートの実行後に自動的に破棄されます。設定が必要なローカル環境も、管理が必要なテストデータベースも、プロビジョニングが必要なインフラも存在しません。
チームは TestSprite をステージングまたはプレビュー環境の URL に向けます。探索エージェントがその URL を訪問し、テストを生成してクラウドサンドボックスで実行します。結果は IDE に返ってきます。テストインフラを一切セットアップすることなく、チームは稼働するテストスイートを手に入れます。
メンテナンス問題への、最初からの対処
レガシーなテストスイートを経験したことのあるチームなら、本当のコストがテストの生成ではないことを知っています。それは 6 か月後もテストを動き続けさせることです。
TestSprite の Auto-Heal Rerun はこの問題に直接対処します。プロダクトの変更後に再実行したテストが失敗した場合、エージェントはその失敗が真の動作上のリグレッションなのか、根本的なフローに影響しない UI の更新なのかを判断します。コンポーネントの名前変更、ボタンの移動、フォームのスタイル変更：テストは誤検知で失敗するのではなく、適応します。
プロダクトの進化に合わせてスイートは常に最新の状態を保ちます。真のリグレッションは明確に浮かび上がります。デザイン変更のたびにセレクタを更新するためのメンテナンスサイクルに時間を費やす必要はありません。
テストスイートと同時に初めて CI を導入するチームにとって、GitHub Actions 連携はパイプラインをプルリクエストのワークフローに直接組み込みます。すべてのコード変更に自動的なカバレッジが適用されます。結果は PR コメントとして投稿されます。テストカバレッジなしの状態から CI 統合の自動テストへの移行が、数か月にわたる移行プロジェクトではなく、一度のセットアップで完了します。
Auto-Auth はログインフローを持つプロジェクトの認証レイヤーを処理します。パスワードエンドポイント、OAuth リフレッシュトークン、AWS Cognito の設定が、すべてのテスト実行前に自動的に処理されます。スケジュールされたリグレッションが古い認証情報で失敗することはありません。
まとめ
既存プロジェクトから自動テストを生成することは、すでに陳腐化したテストスイートを作成するために何週間もかけることを意味する必要はありません。
真に持続するアプローチは、ソースコードではなく稼働中のプロダクトから始めるものです。アプリケーションがどのように動作するかを探索する。観察された動作に基づいたテストを構築する。フロントエンドのフロー、バックエンド API、認証済みパスを含むプロダクト全体をカバーする。これらすべてを単一の起点から実現します。
TestSprite はこれを自律的に行います。探索エージェントは実際のユーザーのようにライブアプリケーションをナビゲートし、観察した内容からテストを生成し、プロダクトの進化に合わせて Auto-Heal でテストを維持します。チームは一つのテストケースも手書きすることなく、テストカバレッジなしの状態から稼働する CI 統合スイートへ移行できます。
TestSprite で既存プロジェクトから最初の自動テストスイートを生成しましょう
今すぐ。