本稿は 結合テスト (IT: Integration Test) に関する記事です。結合テストは、単体テスト (UT) の後段に位置し、複数のモジュール・コンポーネントを組み合わせた状態でシステムが正しく動作するかを確かめる工程です。単体では発見できないI/F の食い違い・データの受け渡し・状態遷移の不整合などを検出するのが目的です。
結合テストの位置づけ
結合テストで確認する観点
| 観点 | 例 |
|---|
| I/F の整合 | API のリクエスト/レスポンス形式、CSV ヘッダ・桁・型 |
| データ受け渡し | 画面 ↔ コントローラ ↔ サービス ↔ DAO ↔ DB の連携 |
| 状態遷移 | セッション・トランザクション・ワークフロー |
| 例外伝播 | 下位の例外が想定どおり上位に渡る／変換される |
| 外部システム連携 | API 呼び出し・メール送信・ファイル転送 |
| 権限と認可 | ロールに応じた API/画面アクセス制御 |
| 性能 | ピーク時の応答時間 (性能テストへの橋渡し) |
結合テストのアプローチ
| アプローチ | 説明 |
|---|
| ボトムアップ | 下位モジュールから順に結合。下位の動作確認が早く取れる |
| トップダウン | 上位 (画面・コントローラ) から結合。スタブで下位を仮置き |
| ビッグバン | すべて結合してから一気にテスト。問題切り分けが難しい |
| サンドイッチ / ハイブリッド | 上下を並行に結合。多くの実プロジェクトで採用 |
| 機能 (Feature) ベース | 1 つの業務シナリオごとに結合する |
スタブ / ドライバ / モック
| 呼び方 | 役割 |
|---|
| スタブ (Stub) | 下位モジュールが未実装の場合に用意する仮実装 (返り値だけ用意) |
| ドライバ (Driver) | 上位モジュールが未実装の場合に下位を呼び出すテスト用ハーネス |
| モック (Mock) | 呼ばれ方を検証できる仮実装 |
| サービス仮想化 | 外部 API・メインフレーム等の応答をシミュレート |
主な成果物
- 結合テスト計画書 — スコープ・体制・期間・テスト環境
- テスト観点・シナリオ・テストケース — 機能ID / 画面ID と紐付け
- テストデータ — マスタ・トランザクション・境界値
- 環境構成資料 — 結合テスト用 DB / API のスタブ・モック
- テスト結果報告書 — 実施件数・OK/NG・欠陥一覧
- 欠陥トラッキング — 起票 → 修正 → 再テストのフロー
典型的なシナリオ例 (Web アプリ)
- ログイン → 画面遷移 → CRUD 操作 → 結果確認 (Happy path)
- 権限が無いユーザでの操作 (403 になるか)
- 入力チェックの境界値 (桁・型・必須・相関)
- セッションタイムアウト中の再操作
- 外部 API 呼び出し失敗時のリトライ・代替動作
- 同時アクセスでの楽観/悲観ロック挙動
- ファイルアップロード・大容量データ・タイムアウト
使われるツール
| 用途 | ツール |
|---|
| API テスト | Postman、Insomnia、curl、HTTPie、Karate |
| E2E (画面操作) | Selenium、Cypress、Playwright、Puppeteer |
| DB セットアップ | DbUnit、Testcontainers、Flyway / Liquibase |
| モック / スタブ | WireMock、MockServer、Hoverfly |
| Java の結合テスト | JUnit 5 + Spring Boot Test (@SpringBootTest)、Testcontainers |
| 負荷 | JMeter、k6、Gatling |
| CI/CD | GitHub Actions、Jenkins、GitLab CI |
結合テストの合格基準 (例)
- 計画したテストケースを100% 実施済み
- 重大度 High の欠陥がすべてクローズ
- 主要な業務シナリオがエラーなく通る
- 同時アクセス・データ量の想定シナリオで応答が SLA 内
- 外部 I/F のフォーマット・タイミングが仕様どおり
- 関係者によるレビューと承認
うまくいかないサイン
- テストデータが本番想定とかけ離れている — 件数 1 件、固定値だけ
- 異常系が抜けている — Happy path しかテストしない
- 環境差を吸収するモックが過剰 — 本物の I/F の不整合を見逃す
- 欠陥の収束が見えない — 毎日新規欠陥が増える状態でリリース判定
- UT を結合テストで肩代わり — 単体で潰すべき欠陥がここに集まる
注意点
- UT で潰す欠陥は UT で潰す。結合テストは I/F・連携の検証に集中する
- テスト環境のデータ管理を仕組み化する (Flyway / Liquibase / fixture)
- 本番相当の負荷で 1 度通す経験を作る (性能課題の先送り防止)
- 個人情報・本番データを検証環境にコピーする場合はマスキング必須
- 欠陥の再現条件・重大度・回避策を必ず記録する
- CI で自動回帰実行できる結合テストを段階的に増やす
関連