前回との接続——網を「いつ走らせるか」へ
前回のP-06では、利用者の主要動線をE2Eテストで少数だけ通す考え方を学びました。単体・結合・E2Eと、確認の網を三階層で張ってきたわけです。この講義は、その積み上げたテストを「いつ走らせるか」に踏み込みます。テストは一度書いて終わりではなく、変更のたびに再び走らせてこそ、真価を発揮します。その繰り返しの守りが、回帰テストです。
このスライドのポイント
- P-06までで、単体・結合・E2Eの三階層でテストの網を張ってきた
- この講義は、積み上げたテストを「いつ走らせるか」に踏み込む
- テストは一度書いて終わりではない。変更のたびに再び走らせてこそ守りになる
定義——既存テスト全部を毎回走らせ直す
回帰テストとは、コードを変更するたびに、既存のテスト全部をもう一度実行して、以前動いていたものが壊れていないかを確認することです。P-04からP-06で書き溜めた単体・結合・E2Eのテストが、そのまま資産になります。これらはテストの自動実行、つまりO-10で触れた自動検査の中身として、毎回一瞬でまとめて走ります。なお、その自動実行を支える実行環境をどう整えるかは、カテゴリRで扱います。ここでは「既存のテストを毎回全部走らせ直す」という考え方そのものを押さえてください。
このスライドのポイント
- 回帰テスト＝変更のたびに、既存のテスト全部を再実行し、以前動いていたものが壊れていないか確認すること
- P-04〜06で書き溜めた単体・結合・E2Eのテストが、そのまま資産になる
- 自動実行＝O-10で触れた自動検査の中身。実行環境の整備はカテゴリRで扱う
なぜ必要か——バイブコーディング最大の恐怖への答え
回帰テストが無いと、バイブコーディング最大の恐怖に無防備になります。「AIに機能Bを直してもらったら、関係ないはずの機能Aが壊れた」という事故です。A-04で学んだ差分確認は変更箇所を見せてくれますが、実際に動かしたときの壊れまでは見切れません。テストが無ければ、変更のたびに全機能を手で確かめ直すか、壊れていないことをただ祈るかの二択になります。どちらも長続きしません。
このスライドのポイント
- 回帰テストが無いと「AIが機能Bを直したら機能Aが壊れた」に無防備
- A-04の差分確認は変更箇所を見せるが、実行時の壊れまでは見切れない
- テストが無い変更は「全機能を手で確かめる」か「祈る」かの二択になる
構造——テスト資産の複利効果
回帰テストの価値は、複利で効いてきます。テストが増えるほど、一回の変更で自動的に走る確認の網が厚くなります。網が厚いほど、AIに大胆な変更を任せても壊れをすぐ捕まえられます。捕まえられるからこそ、確認に時間を取られず開発が速くなり、また次のテストを足せる。この好循環が積み上がっていきます。言い換えれば、テストはAIとの協働の走行レーンです。レーンがあるから、安心して速度を出せるのです。
このスライドのポイント
- テストが増える→変更のたび全部が自動で走る→AIに大胆に変更を任せられる→開発が速くなる→またテストを足せる
- この好循環が積み上がる＝複利効果
- 「テストはAIとの協働の走行レーン」。レーンがあるから安心して速度を出せる
処理の流れ——承認ルール変更で壊れを捕まえる
具体例で見ましょう。経費アプリで、承認ルールの変更をAIに依頼したとします。変更を加えた瞬間、保存済みの41本のテストが自動でまとめて走ります。すると、そのうち2本が失敗しました。ログを見ると、AIの変更が承認とは無関係の集計機能を壊していたと即座に分かります。原因が判明したので修正し、41本すべてが通るのを確認してから、O-08で学んだ手順でマージします。壊れは、公開前にここで捕まりました。
このスライドのポイント
- 経費アプリで、承認ルールの変更をAIに依頼
- 変更した瞬間、保存済みの41本のテストが自動でまとめて走る
- 2本が失敗→AIの変更が無関係の集計機能を壊していたと即判明
- 修正し、41本すべて通ってからO-08の手順でマージ
技術サンプルカード——回帰テストの信号図
スライドのサンプルは、回帰テストの流れを信号図で表したものです。変更を加えると、自動で全テストが実行され、結果が緑か赤かで返ってきます。緑は全部通過、赤はどこかが壊れたという合図です。この仕組みが、O-10で触れた自動検査のパイプラインにそのままつながっています。AIへの質問例はこうです。「この変更で既存テストは全部通っていますか。失敗したテストは、私の依頼と無関係の壊れではないですか」。無関係の壊れこそ、回帰テストが狙う獲物です。
混同しやすい概念——新機能のテスト vs 回帰テスト
混同しやすいのが、新機能のテストと回帰テストの区別です。新機能のテストは、今回作った部分が正しいかという「今回の確認」です。回帰テストは、以前から動いていた部分が無事かという「過去の確認」です。変更のたびに、この両方が必要になります。そして回帰テストは、自動化してこそ成り立ちます。既存のテストを毎回手で全部走らせ直すのは、現実には続かないからです。
バイブコーディングでの確認点——緑を確かめてからコミット
日々の確認点は、「テストが全部通ってからコミットする」をリズムにすることです。O-03で学んだコミットの前に、必ず緑を確認する。この一手間が、回帰の網を守ります。逆に、赤いテストをそのまま放置するのは、自分で張った網に自分で穴を空ける行為です。AIに変更を頼んだあとは、通ったかどうかを毎回聞く習慣をつけましょう。テストは、AIの出力を受け入れてよいかを判定する検収装置なのです。
このスライドのポイント
- 「テストが全部通ってからコミット（O-03）」をリズムにする
- 赤いテストの放置は、自分で張った網に自分で穴を空ける行為
- AIに変更を頼んだあとは、通ったかどうかを毎回聞く
- 質問例:「この変更後、既存テストはすべて緑ですか。赤があれば内容を見せてください」
まとめ——テストは走らせ直してこそ守りになる
最後に一問一答です。AIの変更が、過去の機能を壊していないかを守る仕組みは何でしょうか。（間）答えは、回帰テストです。既存のテストを自動で再実行し、以前動いていたものの無事を毎回確かめます。30秒でまとめます。テストは書いて終わりではなく、変更のたびに全部を走らせ直してこそ守りになります。積み上げたテストは複利で効き、AIとの協働の走行レーンになります。次回P-08では、見つけた不具合を追い詰める入口、再現条件へ進みます。関連資料は「テスト観点プロンプト50」「アプリ改善ログテンプレート」です。
このスライドのポイント
- 一問一答:「AIの変更が過去の機能を壊していないかを守る仕組みは？」→ 回帰テスト（既存テストの自動再実行）
- 30秒まとめ: テストは書いて終わりではなく、変更のたびに全部を走らせ直してこそ守りになる。積み上げは複利で効き、AIとの協働の走行レーンになる
- 次回: P-08 再現条件へ
- 関連資料:「テスト観点プロンプト50」「アプリ改善ログテンプレート」
