マイクロサービスのテスト：固有の課題とその解決策
Yunhao Jiao
マイクロサービスアーキテクチャは、独立したデプロイ可能性、技術的柔軟性、チームの自律性、スケーラビリティの分離といった現実的な課題を解決します。一方で、モノリシックアーキテクチャには存在しないテスト上の問題も生み出します。モノリシックなテストアプローチをマイクロサービスにそのまま適用するチームは、必ずといっていいほど壁にぶつかります。
本ガイドでは、マイクロサービス特有のテスト課題と、実際に効果のあるアプローチを解説します。
マイクロサービスのテストが難しい理由
分散した障害発生面
モノリスでは、リクエストは単一のプロセス内を流れます。何か障害が起きても、それは一か所で発生します。マイクロサービスアーキテクチャでは、ユーザーの一つの操作が5〜15のサービスにまたがることがあります。障害はあらゆる箇所で発生しうるのです。サービス間のネットワークタイムアウト、プロデューサーとコンシューマー間のスキーマ不一致、結果整合性におけるレース条件、一つの低速なサービスが他のサービスをブロックするカスケード障害などが挙げられます。
これらの障害モードはモノリスには存在しません。そしてそのすべてが、マイクロサービス固有のテスト戦略を必要とします。
サービス間のコントラクトドリフト
2つのサービスがAPIで通信する場合、両者はコントラクト（契約）に暗黙的に合意しています。プロデューサーは特定のフォーマットでデータを返し、コンシューマーは特定のフォーマットでリクエストを送るという約束です。モノリスでは、ある関数に変更を加えると呼び出し元は即座に破壊されます（コンパイル時エラー、またはテストエラーとして検出されます）。マイクロサービスでは、あるサービスのAPIレスポンスに変更を加えても、両サービスが一緒にデプロイされるまで——場合によっては本番環境に出るまで——コンシューマー側の問題は表面化しないことがあります。
これを「コントラクトドリフト」と呼びます。マイクロサービスアーキテクチャにおいて最もコストの高いバグの一つです。サービスはそれぞれ独立してデプロイされ、コントラクトの不一致が積み重なり、サービスが実際の条件下で連携したときに障害が顕在化します。
テスト環境の複雑さ
モノリスのテストに必要なのは、1つのアプリケーションを起動することだけです。マイクロサービスアプリケーションのE2Eテストには、すべてのサービスが起動し、正しく設定され、互いにアクセス可能な状態であることが必要です。この環境の複雑さにより、E2Eテストは大幅に困難かつコスト高になります。
多くのチームはテスト内で依存関係をモック化することで対処しますが、これは環境の複雑さをテストの信頼性と引き換えにする行為です。しかし、モックを使ったテストではコントラクトドリフトを検出できません。コントラクトドリフトこそが最も重要な捕捉すべきバグであるにもかかわらず。
独立デプロイ＝独立したテストサイクル
マイクロサービスを価値あるものにしている独立性は、同時にテストの協調を難しくします。各サービスが独自のデプロイパイプラインを持つ場合、サービスをまたぐ結合テストは誰が所有するのでしょうか？一つのチームによるサービス更新が他チームのサービスを壊さないようにするために、テスト実行を調整するにはどうすればよいでしょうか？
マイクロサービスに効果的なテスト戦略
レイヤー1：各サービス内のユニットテスト
各サービスの内部ロジックは、独立してユニットテストされるべきです。これは他のソフトウェアのテストと変わりません。純粋な関数、ビジネスロジック、データ変換が対象です。ユニットテストのスコープは厳密に1つのサービス内に限定され、すべての外部依存関係はモック化されます。
レイヤー2：サービス間のコントラクトテスト
コントラクトテストはマイクロサービステストで最も重要なレイヤーであり、最も頻繁に省略されるレイヤーでもあります。
コンシューマー駆動コントラクトテスト（Pactなどのツールを使用）の仕組みは次の通りです。コンシューマー側のサービスが、プロデューサー側のサービスに期待するコントラクト（特定のリクエスト形式・レスポンス形式）を定義します。プロデューサー側のサービスは、このコンシューマー定義のコントラクトに基づいてテストを実行します。プロデューサーのAPIがコンシューマーの期待を壊すような変更をされた場合、コントラクトテストはデプロイ前に失敗します。
これにより、コントラクトドリフトを本番環境ではなく発生源で検出できます。
TestSpriteは、標準カバレッジの一環としてAPIコントラクトテストを生成します。要件を読み込んでテスト計画を生成する際、各サービスのAPIが下流のコンシューマーの期待するスキーマと動作を返すことを検証するテストが含まれます。
レイヤー3：コンポーネント結合テスト
実際のサービスをペアまたは少数グループでテストします。APIゲートウェイと認証サービス、決済サービスとフルフィルメントサービスといった組み合わせが対象です。このレベルのテストでは、実際のネットワーク呼び出し、実際のデータシリアライゼーション、実際のエラー伝播を伴う実際の結合ポイントを検証します。
コンポーネント結合テストはユニットテストやコントラクトテストよりも低速ですが、フルE2Eテストよりはるかに高速です。また、モック化されたユニットテストでは発見できないバグのクラスを捕捉できます。
レイヤー4：クリティカルフローのE2Eテスト
フルE2Eテストは、分散システム全体にまたがる最も重要なユーザーフローをカバーすべきです。これらのテストは作成・実行コストが最も高いため、優先順位を徹底してください。認証、決済、コア機能の利用、データ整合性が対象となります。
TestSpriteのエージェンティックテストエンジンは、マイクロサービスアーキテクチャ全体のE2Eテストを自動的に処理します。要件を読み込み、サービス境界をまたぐフローを生成し、実際の（またはステージング）デプロイメントに対して実行します。個々のサービスのテストを自分で記述する必要はありません。複数のサービスが連携して正しく動作することに依存する、ユーザー向けフローをカバーします。
マイクロサービス固有のテストパターン
サービス耐障害性のテスト
マイクロサービスは下流の障害を適切に処理できなければなりません。決済サービスが遅い場合は？認証サービスが503を返した場合は？データベースが容量限界に達した場合は？耐障害性テストは、サーキットブレーカー、リトライロジック、フォールバック動作を検証します。
イベント駆動アーキテクチャのテスト
マイクロサービスがメッセージキューやイベントストリームで通信する場合、メッセージの生成と消費を検証するテストが必要です。正しいスキーマで正しいメッセージが発行されること、コンシューマーがメッセージを正しく処理すること、メッセージの順序が適切に扱われること、および不正なメッセージがコンシューマーをクラッシュさせないことを確認します。
分散トランザクションのテスト
ユーザーの操作が複数のサービスにまたがる場合（例：在庫、決済、フルフィルメントを同時に更新する購入処理）、トランザクションの結果整合性を検証するテストが必要です。一部のステップが完了した後に別のステップが失敗した場合、どうなるでしょうか？ユーザーが不整合な状態に置かれることはないでしょうか？
実践的なマイクロサービステストスタック
モダンなマイクロサービスアーキテクチャには以下が必要です。
- サービスごとのユニットテスト（Vitest、Jest、Pytestなど）
- サービス間のコントラクトテスト（PactまたはTestSpriteのコントラクトテストカバレッジ）
- サービスをまたぐクリティカルなユーザーフローのE2Eテスト（TestSprite、フルステージング環境に対して実行）
- すべてのPRでサービスレベルのテストを実行し、サービスコントラクトに変更があった場合は結合テストも実行するGitHub PRゲート
TestSpriteのGitHub連携は、変更内容に基づいて適切なテストスコープをトリガーできます。たとえば、認証サービスへのPRでは、認証サービスのテストに加え、認証サービスのAPIに関わるコントラクトテストも実行されます。
こちらから始める →