統合テスト

統合テストは、独立して開発されたソフトウェアのユニットが、互いに接続されたときに正しく動作するかどうかを判断します。この用語は、ソフトウェア業界の曖昧な標準によってさえも曖昧になっているため、私は自分の文章で使用することをためらってきました。特に、多くの人々は、統合テストは必然的に広範囲なものであると考えていますが、より狭い範囲でより効果的に行うことができます。

これらのことによくあるように、少し歴史から始めるのが最善です。私が初めて統合テストについて学んだのは1980年代で、ウォーターフォールがソフトウェア開発の考え方の支配的な影響力を持っていました。大規模なプロジェクトでは、システムのさまざまなモジュールのインターフェイスと動作を指定する設計フェーズがありました。次に、モジュールはプログラマーに割り当ててプログラミングします。1人のプログラマーが単一のモジュールを担当することは珍しくありませんでしたが、これには構築に数ヶ月かかる可能性がありました。この作業はすべて隔離された状態で行われ、プログラマーが完成したと信じたら、テストのためにQAに引き渡しました。

テストの最初の部分は単体テストで、設計フェーズで完了した仕様に対して、そのモジュール自体をテストします。それが完了したら、統合テストに移行し、さまざまなモジュールをシステム全体、または重要なサブシステムに組み合わせます。

名前が示すように、統合テストの目的は、個別に開発された多くのモジュールが期待どおりに連携して動作するかどうかをテストすることです。これは、多くのモジュールをアクティブ化し、それらすべてに対して高レベルのテストを実行して、それらが一緒に動作することを確認することによって実行されました。これらのモジュールは、単一の実行可能ファイルの一部である場合もあれば、別々の場合もあります。

より2010年代の視点から見ると、これらは2つの異なるものを混同していました。

• 個別に開発されたモジュールが適切に連携して動作することをテストする
• 複数のモジュールで構成されるシステムが期待どおりに動作することをテストする。

これら2つのことは混同しやすかったのです。結局のところ、ショッピングカートとカタログモジュールを、両方を単一の環境にアクティブ化し、両方のモジュールを動作させるテストを実行せずにテストする方法があるでしょうか？

2010年代の視点では、1980年代にはめったに考慮されなかった別の選択肢を提供しています。別の選択肢では、カタログのテストダブルに対して実行して、ショッピングカートとカタログモジュールの統合をテストします。テストダブルがカタログの忠実なダブルを提供する場合、完全なカタログインスタンスをアクティブ化せずに、カタログのすべてのインタラクション動作をテストできます。これらがモノリシックアプリケーションの別々のモジュールである場合は大したことではないかもしれませんが、カタログが独自のビルドツール、環境、およびネットワーク接続を必要とする別のサービスである場合は大変なことです。サービスの場合、このようなテストは、インプロセステストダブルに対して、またはmountebankのようなものを使用して、オーバーザワイヤダブルに対して実行される場合があります。

ダブルに対する統合テストの明らかな問題は、そのダブルが本当に忠実であるかどうかです。ただし、コントラクトテストを使用して、それを個別にテストできます。

狭い統合テストとコントラクトテストのこの組み合わせを使用することで、実際のサービスインスタンスに対するテストを実行することなく、外部サービスとの統合を確信できます。これにより、ビルドプロセスが大幅に簡素化されます。これを行うチームは、すべての実際のサービスを使用して何らかのエンドツーエンドシステムテストを行う場合もありますが、その場合は非常に限られた範囲のパスをテストする最終的なスモークテストにすぎません。成熟したQA in Production機能を持つことも役立ちます。それが十分に成熟していれば、エンドツーエンドのシステムテストはまったく行われない可能性があります。

問題は、統合テストを構成するものについて、少なくとも2つの異なる概念があることです。

狭い統合テスト

• 別のサービスと通信する、自分のサービスのコードの一部のみを実行する
• インプロセスまたはリモートで、これらのサービスのテストダブルを使用する
• したがって、多くの場合、単体テストよりも範囲が広くない、狭い範囲のテストで構成されます（通常、単体テストに使用されるものと同じテストフレームワークで実行されます）。

広い統合テスト

• すべてのサービスのライブバージョンが必要で、実質的なテスト環境とネットワークアクセスが必要になる
• インタラクションを担当するコードだけでなく、すべてのサービスを介したコードパスを実行する

そして、「統合テスト」が「広い統合テスト」のみを意味すると考えるソフトウェア開発者が多数いるため、狭いアプローチを使用する人々に出会うと混乱が生じます。

統合テストが広いものだけの場合、狭いスタイルを検討する必要があります。これは、テスト速度、使いやすさ、および回復力を大幅に向上させる可能性があるためです。狭い統合テストは範囲が限られているため、多くの場合、非常に高速に実行され、デプロイメントパイプラインの初期段階で実行できるため、赤になった場合にすばやくフィードバックが得られます。

この用語の混乱だけでは不十分な場合、2010年代後半には「統合テスト」の別の使用法で事態が悪化しています。これは、単体テストの意味の相違から来ています。一部の人々は、単体テストを、私が孤独な単体テストと呼ぶもの、つまり、テスト対象のプログラム要素以外のすべての要素がテストダブルに置き換えられたものと定義しています。この狭い定義を考えると、「統合テスト」を社交的な単体テストを意味すると定義するライターもいます。

これが、私が「統合テスト」を警戒する理由です。それを読むときは、著者が実際にどの種類を意味しているのかを知るためにより多くのコンテキストを探します。広い統合テストについて話す場合は、「システムテスト」または「エンドツーエンドテスト」を使用することを好みます。狭い統合テストに適した名前がないため、私はそれを使用しますが、（これらのテストの性質を読者に知らせるために）「狭い」という言葉を添えます。必要に応じて区別するために、孤独/社交的なものを使用して、両方の種類の「単体テスト」を引き続き使用します。