複数のモジュール・コンポーネント・外部システム（DB・API）の連携を検証するテスト。単体テストでは検出できない結合点のバグを発見する。
概要
単体テスト は依存を全てモック化して純粋に振る舞いを見るが、 実際の本番では複数のモジュール・DB・外部 API が連動する 。結合点に潜むバグ（型ミスマッチ・SQL 誤り・API 仕様差異・トランザクション境界）は単体だけでは検出できない。
| 観点 | 結合テストの特徴 |
|---|---|
| 対象 | モジュール間 / リポジトリ + DB / API クライアント + サーバ |
| 速度 | 数百 ms 〜 数秒 |
| 件数の目安 | 数十〜数百 |
| 外部依存 | 本物または Fake / Testcontainer で再現 |
| 主な検証 | 連携 / 永続化 / 通信プロトコル / トランザクション |
代表的なツール
| 用途 | ツール |
|---|---|
| DB をコンテナ起動 | Testcontainers / Docker Compose |
| HTTP モックサーバ | MSW（Mock Service Worker）/ WireMock |
| 契約テスト（API 互換性） | Pact / Spring Cloud Contract |
| GraphQL | apollo-server-testing |
モダンな結合テストの基本姿勢
Mock より Fake / 本物寄せ
単体テストでは Mock を多用するが、結合テストは 「本物に近い再現」 が肝。
| アプローチ | 評価 |
|---|---|
| 全モック | △ 単体テストになってしまう |
| Fake（インメモリ DB 等） | ○ 速いが本番との差が残る |
| Testcontainer で本物の DB | ◎ 本番と同等、CI でも秒で起動 |
Testing Trophy では中心
テストトロフィー では、結合テストを 最も厚く 配置する。理由は「実本番に近い検証ができ、モック過剰の罠を避けられる」から。
AI 駆動開発との関係
結合テストは 人間が骨組みを作って AI に拡張させる のが定石。設定（Testcontainer 起動・テストデータ準備）が複雑なため、AI に丸投げすると無駄に複雑化することがある。
| 役割分担 | 内容 |
|---|---|
| 人間 | テスト基盤（コンテナ設定・共通フィクスチャ）を整備 |
| AI | 個別シナリオの実装と網羅性追加 |
| 人間 | 本番との乖離をレビュー |
関連記事
- 開発手法ガイド：テスト技法編 — 結合テストの位置づけ
- 開発手法ガイド：SOLID 原則編 — 結合点を疎結合に保つ設計
- 開発手法ガイド：DDD 編 — Bounded Context 間の結合点を明示