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