結合テストとV字モデルの対応関係
V字モデルでは結合テスト（Integration Test）は基本設計と対応します。単体テストで個々のモジュールを検証した後、複数のモジュールを組み合わせてインターフェース（API・DB・外部連携）が正しく機能するかを確認するフェーズです。
単体テストが「部品の品質検証」であるのに対し、結合テストは「部品を組み合わせたときに設計通りに動くか」を検証します。API のリクエスト・レスポンスの形式、DB スキーマとのマッピング、外部サービスとの連携など、モジュール境界の欠陥を発見することが主目的です。
INPUTドキュメント — 何を読んでテストを設計するか
結合テスト仕様書を作成するにあたり、基本設計フェーズで作成された以下のドキュメントが主なINPUTになります。
| INPUTドキュメント | 参照目的 | 確認箇所 |
|---|---|---|
| 基本設計書（内部 API 仕様書） | テスト対象の API エンドポイント・リクエスト/レスポンス仕様を把握する | HTTP メソッド・URL・リクエストボディ・レスポンスボディ・ステータスコード・認証方式 |
| 外部インターフェース定義書 | 外部システム・ファイル連携の仕様を確認し、スタブ・モックサーバーの設計に使う | 連携先システム・プロトコル・データフォーマット・エラーコード |
| テーブル定義書・ER図 | DB の期待状態（INSERT/UPDATE/DELETE 後のレコード）を検証するための基準にする | テーブル定義・制約・インデックス・リレーション |
| バッチ処理設計書 | バッチジョブの入出力・エラーハンドリング・リカバリー手順を確認する | 処理フロー・入力ファイル仕様・出力ファイル仕様・エラー時の動作 |
💡 OpenAPI（Swagger）をINPUTとして活用する
API 仕様書が OpenAPI 形式で定義されている場合、Postman・REST Assured どちらも OpenAPI をインポートしてテストを自動生成できます。仕様書の変更がテストに直結するため、仕様と実装の乖離を早期に発見できます。
作成ドキュメントの構成
① 結合テスト仕様書
結合テスト仕様書はテストシナリオ・テストケース・テストデータ・期待結果を定義します。API テストの場合は以下の項目を記載します。
| 記載項目 | 内容 | 例 |
|---|---|---|
| テストケースID | 一意の識別子 | IT-USER-001 |
| テストシナリオ | 複数のAPIを連続して呼び出す業務シナリオ | ユーザー登録 → ログイン → プロフィール取得 |
| テスト対象API | HTTP メソッド + エンドポイント | POST /api/users |
| リクエスト | ヘッダー・ボディ・クエリパラメータ | Content-Type: application/json / ボディ: {"name":"田中",...} |
| 期待レスポンス | ステータスコード・レスポンスボディの形式・値 | HTTP 201 / ボディに id フィールドが存在する |
| DB期待状態 | API 実行後の DB レコードの状態 | users テーブルに1件追加、created_at が現在時刻 |
| 前提条件・テストデータ | テスト実行前に投入するデータ・環境条件 | users テーブルが空の状態 / 認証トークンが有効 |
② テストデータ定義書
結合テストでは実データに近い形でテストを行うため、テストデータの管理が重要です。テストデータ定義書には「初期投入データ」「テストケースごとのデータ差分」「後片付け（クリーンアップ）手順」を記載します。Testcontainers を使うとテストごとに DB コンテナを起動・破棄できるため、データの汚染問題を根本から解決できます。
確認ポイント
| 観点 | 確認内容 | 優先度 |
|---|---|---|
| API 契約（正常系） | 全エンドポイントで正しいリクエストを送ると仕様通りのレスポンスが返ること | 必須 |
| API 契約（異常系） | 不正なリクエスト・認証エラー・存在しないリソースで適切なエラーレスポンスが返ること | 必須 |
| DB 整合性 | CREATE/UPDATE/DELETE 後に DB のレコードが仕様通りの状態になること | 必須 |
| 外部サービス連携 | 外部APIへの呼び出しが正しいパラメータで行われ、レスポンスが適切に処理されること | 必須 |
| トランザクション | 複数テーブルへの更新がアトミックに実行され、エラー時にロールバックされること | 推奨 |
| コントラクトテスト | Consumer/Provider 間の API 仕様が合意通りであること（Pact） | 推奨 |
| エラーハンドリング | DB 接続エラー・タイムアウト・外部サービス障害時に適切なエラーレスポンスが返ること | 推奨 |
利用ツール — Postman / REST Assured / Testcontainers / Pact
Postman（APIテスト・コレクション管理）
Postman は GUI ベースの API テストツールです。コレクション単位でテストケースを管理し、Newman（CLI）を使って CI/CD に組み込めます。環境変数機能を使うことで、開発・ステージング・本番環境を切り替えてテストを実行できます。テストスクリプトを JavaScript で記述し、レスポンスの値を動的に検証することも可能です。
REST Assured（Java の API テスト DSL）
REST Assured は Java で API テストを記述するための DSL ライブラリです。JUnit 5 と組み合わせて使用でき、テストコードとして管理できる点が Postman と異なります。given().when().then() の流暢なAPIで可読性の高いテストが書けます。Spring Boot のテストスライスと組み合わせると、サーバーを起動せず MockMvc 経由でテストすることも可能です。
Testcontainers（DB・外部サービスのコンテナ化）
Testcontainers は JUnit 5 のテストライフサイクルに連動して Docker コンテナを起動・停止するライブラリです。PostgreSQL・MySQL・Redis・Kafka などのコンテナをテスト開始時に自動起動し、テスト終了後に破棄します。これにより「テスト用 DB が汚染される」「ローカルと CI で DB のバージョンが異なる」という問題を解消できます。
Pact（コントラクトテスト）
マイクロサービスアーキテクチャでは、Consumer（API を呼び出す側）と Provider（API を提供する側）の間で期待するリクエスト/レスポンスの形式が合意されていることを自動検証するコントラクトテストが重要です。Pact を使うと、Consumer がテストを通じて「Pact ファイル」を生成し、Provider がそのファイルを使って自分の API が Consumer の期待に応えられるかを独立して検証できます。
よくある落とし穴と対策
⚠️ テストデータの汚染
結合テストでは実際の DB を使うため、テスト間でデータが残留すると後続テストに影響します。Testcontainers でテストごとに DB を初期化するか、各テストケースで明示的にクリーンアップを実施してください。
⚠️ スタブの不一致
外部サービスをスタブで代替した場合、スタブの挙動が実際のサービスと乖離していると、本番環境で初めて不具合が発覚します。WireMock などを使い、実際の外部 API レスポンスを記録してスタブに使用することで乖離を防ぎます。
⚠️ テストの順序依存
「ユーザー登録 → ログイン → データ取得」という一連の API を同じテストメソッドで実行すると、テストが長くなりデバッグが困難になります。各 API の検証は独立したテストケースとし、必要なデータは前提条件として事前にセットアップしてください。
まとめ
結合テストフェーズで定義すべき3つのポイントを整理します。
- INPUT：基本設計書（API仕様）・外部IF定義書・テーブル定義書・バッチ処理設計書
- 作成ドキュメント：結合テスト仕様書（シナリオ・リクエスト・期待レスポンス・DB期待状態）＋テストデータ定義書
- 確認ポイント：API 契約（正常系・異常系）・DB 整合性・トランザクション・外部連携・エラーハンドリング
Postman は非エンジニアも参加できる可視性の高い API テスト管理に向いており、REST Assured はコードとして管理しCI自動化したい場合に向いています。Testcontainers はテスト環境の再現性を高め、Pact はマイクロサービス間の契約を自動化します。プロジェクトの規模・構成に応じてこれらを組み合わせてください。
✅ 次のステップ
結合テスト仕様書の作成が完了したら、次は「システムテスト仕様書」へ。機能要件の全体網羅・性能・セキュリティなどシステム全体を検証するフェーズに進みます。