結合テスト

一言でいうと

単体で確認した部品を組み合わせ、部品どうしや外部のシステムとのやり取りが正しく行われるかを確認するテストです。

提唱者と登場年

米国電気電子学会（IEEE）が1990年に承認したソフトウェア工学の用語集規格IEEE 610.12-1990は、結合テストを「ソフトウェアの部品、ハードウェアの部品、またはその両方を組み合わせ、それらの間の相互作用を評価するために行うテスト」と定義しています。この定義は、欧州の宇宙分野の標準化機関の用語集など、後続の規格に引用されています。

テスト技術者の資格を運営するJSTQBのFoundation Levelシラバス（2023年版の日本語訳）は、結合テストを2つのテストレベルに分けています。コンポーネント統合テストは部品間のインターフェースと相互処理を対象にし、システム統合テストは対象のシステムと他のシステムや外部サービスとのインターフェースを対象にします。

何を解決するか

部品単体では正しく動いていても、組み合わせると失敗する不具合を見つけます。代表的な原因は、呼び出す側と呼ばれる側でデータの形式や単位の想定が違う、エラー時の返し方の取り決めが無い、処理の順序やタイミングに依存している、の3つです。これらは部品を切り離して行う単体テストでは表れません。

外部サービスとの接続を含む場合、相手側の環境をどこまで用意できるかがテストの範囲を左右します。本番に近い環境を用意するには費用と調整が必要になるため、どの接続を本物で確かめ、どこを代替の仕組みで済ませるかを計画の段階で決めます。

実際の進み方

組み合わせる順序を決める方式として、下位の部品から順に組み上げるボトムアップ、上位から組むトップダウン、まとめて一度に組むビッグバンがあります。JSTQBのシラバスは、コンポーネント統合テストがこうした統合の方式に大きく依存すると説明しています。

自社サービスの開発では、APIやデータベースを実際に起動した状態で動かす自動テストとして書き、CIで実行する例が多くあります。受託開発の工程では、単体テストの後、システムテストの前に置かれ、テスト項目表に沿って実施されます。

導入でよくある失敗

• 単体テストで確認済みの内容を結合テストで繰り返し、部品間のやり取りの確認が薄くなる
• 外部サービスをすべて代替の仕組みで置き換え、本物との接続で初めて不整合が見つかる
• テストデータの準備を人手に頼り、実行のたびに結果が揺れる

求人票にこの語がある場合に読み取れること

「結合テストまで担当」と書かれた求人は、工程を分けた開発体制で、実装者が結合テストの実施まで担当する構成だと読み取れます。一方、自社サービスの組織で「インテグレーションテスト」と書かれる場合は、テストコードとして自動化された検査を指すことが多くなります。候補者には、テスト環境をどう用意したか、外部サービスとの接続をどこまで本物で確かめたかを確認してください。

隣接手法との違い