エンド ツー エンド テストとは、アプリケーションを外側の境界から実行して、その動作を検証することを意味します。これまでのところ、単一の実行可能なアーティファクトのテストを書いただけです。異なるホストにデプロイされた複数のアーティファクトで構成されるシステムをテストするにはどうすればよいですか?
2つの選択肢があります。
これらの 1 つだけに固執する明確なケースはありますか、それともどちらかが優先されますか、それとも互換性がありますか? 互換性がある場合、それらの間の利点と欠点は何ですか?
各アーティファクトをエンドツーエンドで個別にテストすることは、どのような場合でも非常に望ましいことです。これにより、すべてのアーティファクトが確実に健全になります。
さらに、アーティファクトの構成をテストすることもできます。これにより、アーティファクト間の相互作用の問題が発生します。あなたの状況についてはわかりませんが、重要なことの1つは、本番環境のコピーであるテスト環境です。テスト環境でシステムをテストすることは非常に良い考えです。また、実稼働環境でシステムをテストすることもできます。これは実行可能かどうかはわかりません。たとえば、システムがクレジットカードによる支払いを処理する場合、本番システムでのテスト支払いを避けたい場合があります。
いずれにせよ、各システムを個別にテストすることは、構成をテストすることよりも重要です。アーティファクトが孤立して健全であることがわかったら、相互作用テストをキャッチするのははるかに簡単になります。システム全体のエンドツーエンドのテストしかない場合、テストが失敗したときにエラーがどこにあるかを理解するのははるかに困難です。
文脈にもよると思いますが、私は最初の選択肢を好みます。ここに私のランダムな考えがあります：
私は、自分のテストができるだけユース ケース (BDD スタイル) に密接にマッピングされることを好みます (ユース ケースという用語を誤用しているという免責事項があります)。これらの使用例は、複数のアプリケーションとサブシステムにまたがる場合があります。
例:バック オフィスの管理者は、パブリック インターフェイスからユーザーが行ったトランザクションを表示できます。
ここで、バック オフィス管理インターフェイスとパブリック インターフェイスは異なるアプリケーションですが、同じユース ケースに含まれています。
これらの考えを、さまざまなホストに展開されたサブシステムがある問題に当てはめると、ユーザー/アクターの観点から、それがどのように使用されるかに依存すると言えます。ユースケースは複数のサブシステムにまたがっていますか?
また、おそらく、システムが複数のホストにデプロイされているという事実は、テストにとって重要ではありません。テストでプロセス間通信をメソッド呼び出しに置き換え、テスト中にシステム全体を同じプロセス内に配置して、複雑さを軽減できます。プロセス間通信のみを検証するテストでこれを補足します。
編集：
システム全体をテストすることを好む理由を含めるのを忘れていたことに気付きました。
資産は機能、つまり動作ですが、コードは負債です。したがって、コードではなく動作をテストする必要があります (BDD スタイル)。
各サブシステムを個別にテストしている場合は、機能ではなくコードをテストしています。なんで？システムをサブシステムに分割したとき、いくつかの技術的な理由に基づいて分割しました。さらに学習すると、選択したシームが最適ではなく、あるサブシステムから別のサブシステムに責任を移したいと思うかもしれません。また、テスト コードと本番コードを同時に変更する必要があり、セーフティ ネットがなくなります。これは、実装の詳細をテストする際の典型的な症状です。
とはいえ、この種のテストは単純すぎるため、すべてをテストすることはできません。したがって、必要に応じて、詳細についても補完的なテストを行う必要があります。