前回の続き——部品は正しい、では全体は？
単体テストは、部品の中身が正しいかを一つずつ保証してくれる強力な道具でした。ところが、部品が全部正しくても、つなげた瞬間に動かなくなることがあります。バイブコーディングでは、画面とサーバーをAIに別々に作らせる場面が多く、この「つないだら動かない」が起きやすいのです。今回の結合テストは、その事故が集まる接続部分に網を張り、AIの出力を全体としても検収するための回です。
このスライドのポイント
- P-04の単体テスト: 部品の中身を一つずつ保証する道具
- しかし部品が全部正しくても、つなげた瞬間に動かないことがある
- バイブコーディングでは画面とサーバーをAIに別々に作らせる場面が多い
- 今回はその事故が集まる「接続部分」に網を張る
結合テストの定義——狙い所は3つのつなぎ目
結合テストとは、複数の部品をつないだ状態で、その接続部分を検証するテストです。狙い所は3つのつなぎ目です。1つ目はフロントとAPIの間で、K-02で学んだ契約どおりに要求と応答がやり取りされているか。2つ目はサーバーとデータベースの間で、保存した値と取り出した値が対応しているか。3つ目は自分のアプリと外部サービスの間です。単体テストが部品の中身の確認なら、結合テストは配線の確認だと考えてください。
このスライドのポイント
- 結合テスト＝複数の部品をつないだ状態で、接続部分を検証するテスト
- つなぎ目①: フロント⇄API（K-02の契約どおりか）
- つなぎ目②: サーバー⇄DB（L章・保存した値と取得した値が対応するか）
- つなぎ目③: 自分⇄外部サービス（K-06）
- 単体は部品の中身、結合は配線の確認
なぜ必要か——単体は全部通るのに動かない
結合テストがないと、単体は全部通るのに全体は動かない、という状況を説明できません。多くの場合、原因はつなぎ目にあります。K-02の契約が両側で食い違っていたり、K-04で学んだ型がずれていたりするのです。部品が1つずつ完璧でも、配線がつながっていなければ機能しません。単体テストの緑色だけを見て安心すると、この落とし穴にはまります。
このスライドのポイント
- 結合テストがないと「単体は全部通るのに全体は動かない」を説明できない
- 原因の多くはつなぎ目にある
- K-02の契約が両側で食い違う／K-04で学んだ型がずれる
- 部品が完璧でも、配線がつながっていなければ機能しない
構造——テストの3階層、その真ん中
テストには階層があります。下段が部品の中を見る単体テスト、中段が今回のつなぎ目を見る結合テスト、上段が全体を通して見るテストで、これは次回のE2Eテストで扱います。結合テストが受け持つのは、事故が最も集まる真ん中の層です。なぜつなぎ目に事故が集まるのでしょうか。契約は両側の思い込みがずれやすい場所だからです。これはA-06で見た、AIが文脈を取りこぼして起きるずれと同じ構造です。
このスライドのポイント
- テストには階層がある
- 下段: 単体テスト（部品の中）／中段: 結合テスト（つなぎ目）／上段: 全体（次回のE2Eテスト）
- 結合テストは事故が最も集まる真ん中の層
- つなぎ目に事故が集まる理由＝契約は両側の思い込みがずれる場所（A-06の文脈欠落と同じ構造）
Webアプリでの具体例——申請APIをつないで確かめる
経費アプリの申請APIを例にします。結合テストでは、実際に申請データを送り、データベースに行が1件増えたか、そして返ってきた応答がK-02の契約どおりの形かを確かめます。単体テストのように部品を切り離すのではなく、あえてつないで動かすのがポイントです。フロントとサーバーをAIに別々に作らせると、片方が想定した項目名と、もう片方の項目名が微妙に食い違う、といったことが起きます。結合テストは、この「つないだら動かない」を人手ではなく機械で検知する網になります。
このスライドのポイント
- 経費アプリの申請APIを例に
- 結合テスト: 実際に申請データを送り、DBに行が1件増えたかを確認
- 返ってきた応答がK-02の契約どおりの形かを確認
- 単体のように切り離さず、あえてつないで動かすのがポイント
- フロントとサーバーをAIに別々に作らせた「つないだら動かない」を機械で検知
技術サンプルカード——つなぎ目3箇所の構成図
サンプルの種別は構成図です。画面、API、データベース、外部サービスを一列に並べ、その間にある3つのつなぎ目に番号を振りました。1つ目は画面とAPIの契約、2つ目はサーバーとデータベースの保存と取得、3つ目は外部サービスとやり取りする値の型と失敗時の動きです。読み方のこつは、四角の部品そのものではなく、部品と部品の間の矢印に注目することです。AIには、この機能のつなぎ目を列挙し、それぞれで何を確認すべきかを提案してもらいましょう。
混同しやすい概念——単体テストと結合テスト
単体テストと結合テストは、守る場所も性質も違います。単体テストは部品の中を見て、速く、数多く用意します。結合テストはつなぎ目を見て、やや重く、要所に絞って用意します。数の配分は、単体を多め、結合は要所だけ、というのが定石です。どちらが上ということではなく、見ている場所が違うのだと理解してください。単体の緑色と結合の緑色は、別々の安心を意味します。
バイブコーディングでの確認点——契約が一致するテストはあるか
AIに機能を作らせたら、フロントとサーバーの契約が一致しているかを確かめるテストはありますか、と聞く習慣をつけましょう。K-02で作った契約の一覧が手元にあれば、それをそのままテストへ翻訳させることもできます。つなぎ目は目で追いにくい場所なので、確認を言葉にして渡すことが、AIの精度を上げる近道です。結合テストは、AIの出力をつなぎ目で検収する装置だと考えてください。
このスライドのポイント
- AIに機能を作らせたら「フロントとサーバーの契約が一致しているかのテストはありますか」と聞く
- K-02で作った契約の一覧があれば、そのままテストへ翻訳させられる
- つなぎ目は目で追いにくい場所——確認を言葉にして渡す
一問一答とまとめ
一問一答です。単体テストが全部OKでも壊れるのは、どこでしょうか。……答えは、つなぎ目です。部品どうしの接続部分こそ、結合テストの守備範囲です。30秒まとめとして、結合テストは3つのつなぎ目、つまり画面とAPIの契約、サーバーとデータベースの保存、外部サービスとの型を、つないだ状態で確かめるテストだと覚えてください。次回は、利用者の視点で操作経路をまるごと通すE2Eテストへ進みます。関連資料は「API連携 超入門」と「テスト観点プロンプト50」です。
このスライドのポイント
- 一問一答: 単体が全部OKでも壊れる場所は？ → つなぎ目（接続部分。結合テストの守備範囲）
- 30秒まとめ: 結合テスト＝3つのつなぎ目（契約・保存・型）を、つないだ状態で確かめる
- 次回: 利用者の視点で操作経路をまるごと通すE2Eテストへ
- 関連資料: 「API連携 超入門」「テスト観点プロンプト50」
