Contents
マイクロサービステストの全体像と必須テストタイプ
マイクロサービスは 多数の独立プロセスがネットワークで結合 された構造です。その分散特性ゆえに、単体テストだけでは データ不整合・レイテンシ・障害伝播 といったリスクを網羅できません。本章では、実務で欠かせないテストタイプを整理し、各テストが担う役割と期待効果を簡潔に示します。
ユニットテスト
コードレベルのロジック正確性を高速に検証する基礎的なテストです。
- 目的：メソッド／クラス単位で入力‑出力を確認し、外部依存はモックで置き換える。
- ポイント：テスト実行時間がミリ秒レベルになるため、CI のプルリクエスト段階で即時フィードバックが得られます。
統合テスト
複数コンポーネントが正しく連携できるかを検証します。
- 目的：Spring Bean、データベース、メッセージブローカーなど実際のインフラに近い環境で動作確認する。
- ポイント：Docker コンテナや Testcontainers を使うと、本番に近い構成をコードだけで再現できます。
契約テスト（Consumer‑Driven Contract）
サービス間 API の合意内容が破られていないかを自動的にチェックします。
- 目的：Consumer が期待するリクエスト／レスポンス形状と Provider が提供する実装を同期させる。
- ポイント：Pact などのツールで契約ファイル（JSON）を生成し、CI に組み込むだけでバージョンアップ時の破壊的変更を防げます。
負荷・パフォーマンステスト
高トラフィック下での応答性とリソース使用率を測定します。
- 目的：SLA（例：95％ リクエストが 200 ms 以下）を満たすか、ボトルネックはどこにあるかを把握する。
- ポイント：JMeter や Gatling といったツールでシナリオを書き、CI に組み込むと回帰的な性能評価が可能です。
5 種類のテストをバランスよく実装すれば、マイクロサービスは 「部分的に動く」 状態から 「安定して本番稼働できる」 状態へと進化します。
実務で活用できるJava向けテストツールと導入手順
この章では、最新の安定リリース を基準にした主要ツールを機能別に紹介し、実際にプロジェクトへ組み込むための サンプルコード／設定例 を提示します。テストタイプごとに対応ツールを整理しているので、重複する説明は意図的に排除しています。
ユニットテスト・モック系ツール
JUnit 5（最新安定版）
JUnit は Java エコシステムのデファクトスタンダードです。以下は パラメータ化テスト と 条件付き実行 のサンプルです。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
import org.junit.jupiter.api.*; import org.junit.jupiter.params.ParameterizedTest; import org.junit.jupiter.params.provider.CsvSource; class CalculatorTest { @ParameterizedTest(name = "{0} + {1} = {2}") @CsvSource({"1,2,3", "5,7,12", "-3,3,0"}) void add(int a, int b, int expected) { Assertions.assertEquals(expected, Calculator.add(a, b)); } @Test @EnabledOnOs(OS.WINDOWS) void onlyOnWindows() { // Windows 固有ロジックのテスト例 } } |
Mockito（最新安定版）
モックオブジェクト作成をシンプルにする DSL が特徴です。静的メソッド のモック例は次の通りです。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
import static org.mockito.Mockito.*; import org.junit.jupiter.api.Test; import org.mockito.MockedStatic; class ServiceTest { @Test void shouldUseStaticHelper() { try (MockedStatic<TimeUtil> mocked = mockStatic(TimeUtil.class)) { mocked.when(TimeUtil::now).thenReturn(Instant.parse("2023-01-01T00:00:00Z")); // Service が内部で TimeUtil.now() を呼ぶケース Assertions.assertEquals("2023-01-01", new Service().today()); } } } |
Spring Test（Spring Framework 6 系）
@WebMvcTest と MockMvc の組み合わせで コントローラ単体 のテストが高速に走ります。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
import org.junit.jupiter.api.*; import org.springframework.boot.test.autoconfigure.web.servlet.WebMvcTest; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.test.web.servlet.*; @WebMvcTest(UserController.class) class UserControllerTest { @Autowired MockMvc mockMvc; @Test void getUser_returns200() throws Exception { mockMvc.perform(get("/users/1")) .andExpect(status().isOk()) .andExpect(jsonPath("$.id").value(1)); } } |
統合テスト・契約テスト系ツール
Testcontainers（最新安定版）
Docker コンテナを テストコード内で起動 でき、データベースやメッセージブローカーの実環境に近い状態を再現します。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
import org.testcontainers.containers.PostgreSQLContainer; import org.junit.jupiter.api.*; class RepositoryIntegrationTest { static PostgreSQLContainer<?> postgres = new PostgreSQLContainer<>("postgres:15") .withDatabaseName("testdb") .withUsername("user") .withPassword("pwd"); @BeforeAll static void start() { postgres.start(); } @AfterAll static void stop() { postgres.stop(); } @Test void findById_returnsEntity() { // DataSource をコンテナの JDBC URL に差し替えて DAO を実行 String jdbcUrl = postgres.getJdbcUrl(); // ... DAO 呼び出しロジック } } |
Pact JVM（最新安定版） – Consumer 側例
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 |
import au.com.dius.pact.consumer.*; import org.junit.jupiter.api.Test; class OrderClientPactTest { @Pact(consumer = "order-service-client", provider = "order-service") public RequestResponsePact createPact(PactDslWithProvider builder) { return builder.given("注文ID 123 が存在する") .uponReceiving("GET /orders/123") .path("/orders/123") .method("GET") .willRespondWith() .status(200) .body("{\"id\":123,\"status\":\"CONFIRMED\"}") .toPact(); } @Test void shouldReturnOrder(@MockServer MockServer mockServer) { OrderClient client = new OrderClient(mockServer.getUrl()); Order order = client.fetch(123); Assertions.assertEquals("CONFIRMED", order.getStatus()); } } |
Karate（最新安定版） – Gherkin で API と UI を一括管理
order.feature
|
1 2 3 4 5 6 7 8 9 10 11 |
Feature: 注文サービスの統合テスト Background: * url 'http://localhost:8080' Scenario: 新規注文を作成し、ステータスが CONFIRMED になること Given request { productId: 42, quantity: 3 } When method post /orders Then status 201 And match response.status == 'CONFIRMED' |
karate-config.js（Docker Compose 環境への接続例）
|
1 2 3 4 5 6 |
function fn() { var config = { baseUrl: 'http://order-service:8080' }; karate.configure('readTimeout', 5000); return config; } |
コンテナ／インフラ連携系ツール
| ツール | 主な用途 | メリット | デメリット |
|---|---|---|---|
| MockServer | HTTP/HTTPS のリクエストマッチング・レート制限シミュレーション | 高度な JSONPath マッチング、Docker イメージが公式提供 | コンテナサイズが大きく CI 起動に数秒余分 |
| Hoverfly Java | 軽量プロキシ型スタブ（K8s ConfigMap でシナリオ管理） | 起動が高速、Kubernetes ネイティブな運用が容易 | 機能拡張が限定的で複雑シナリオには不向き |
ツール選定の比較軸とスコアリングガイド
本節では 自社プロジェクトに最適なツールを客観的に評価 できる指標体系を提示します。各軸は「重要度（%）」「評価点（5 点満点）」の二段階で数値化し、総合スコアを算出します。
比較軸と重み付け例
| 軸 | 説明 | 重み（例） |
|---|---|---|
| テスト対象範囲 | ユニットから統合・契約まで網羅できるか | 30% |
| 実装容易性 | API のシンプルさとサンプルコードの充実度 | 20% |
| Docker/K8s 親和性 | コンテナ起動や環境変数注入の自動化レベル | 15% |
| CI/CD 連携 | GitHub Actions・Jenkins 等公式プラグイン有無 | 15% |
| ドキュメント品質 | バージョン別ガイドとチュートリアル数 | 10% |
| コミュニティ活性度 | スター数、月間 PR、Slack 活動量 | 5% |
| ライセンス・コスト | 商用利用制限の有無とサポート費用 | 5% |
スコアリング例（仮想評価）
| ツール | 対象範囲 | 実装容易性 | Docker/K8s | CI/CD | ドキュメント | コミュニティ | ライセンス | 合計点 |
|---|---|---|---|---|---|---|---|---|
| JUnit + Mockito | 3/5 | 5/5 | 2/5 | 4/5 | 5/5 | 5/5 | 5/5 | 29 |
| Spring Test | 4/5 | 4/5 | 4/5 | 5/5 | 5/5 | 4/5 | 5/5 | 31 |
| Testcontainers | 5/5 | 3/5 | 5/5 | 5/5 | 4/5 | 4/5 | 5/5 | 31 |
| Pact JVM | 5/5 | 3/5 | 3/5 | 5/5 | 4/5 | 4/5 | 5/5 | 29 |
| Karate | 5/5 | 4/5 | 4/5 | 5/5 | 4/5 | 4/5 | 5/5 | 31 |
実務的な選定フロー
1. 上記の重み付けを自社プロジェクトに合わせて調整。
2. 各ツールの評価点（5 点満点）を掛け算し、総合スコアを算出。
3. スコア上位 2〜3 件で パイロット実装 を行い、ビルド時間・テスト安定性を測定。
ブランド視点でのベストプラクティスと導入チェックリスト
Acme Cloud が提供する「マイクロサービス テスト基盤」への組み込み例
Acme Cloud は フルマネージド Kubernetes と 統合 CI/CD（GitHub Actions / GitLab Runner） を提供しています。以下は当社プラットフォーム上で先述のツール群を標準化する手順です。
- プロジェクト作成
-
Acme Cloud コンソールで Java Microservice テンプレートを選択。テンプレートには
pom.xmlに JUnit、Mockito、Testcontainers の依存が予め宣言されています。 -
GitHub Actions ワークフローの自動生成
yaml
name: CI
on: [push, pull_request]
jobs:
test:
runs-on: ubuntu-latest
services:
postgres:
image: postgres:15
env:
POSTGRES_USER: user
POSTGRES_PASSWORD: pwd
POSTGRES_DB: testdb
ports: ["5432:5432"]
options: >-
--health-cmd="pg_isready -U user"
--health-interval=10s
--health-timeout=5s
--health-retries=5
steps:
- uses: actions/checkout@v3
- name: Set up JDK 21
uses: actions/setup-java@v3
with:
distribution: temurin
java-version: '21'
- name: Build & Test
run: ./mvnw verify -
Pact Broker の統合（Acme Cloud が提供する SaaS）
-
pact-brokerエンドポイントを環境変数PACT_BROKER_URLに設定。CI でpact:publishタスクを走らせるだけで、全チームが最新契約を参照できます。 -
負荷テストの自動実行
- Acme Cloud の Performance Studio と連携し、GitHub Actions に以下ステップを追加すれば、プルリクエストごとに Gatling シナリオが走ります。結果はダッシュボードで可視化。
yaml
- name: Run Gatling Load Test
uses: gatling/gatling-action@v1
with:
simulationClass: com.acme.LoadSimulation
導入チェックリスト（Acme Cloud 向け）
| ✅ チェック項目 | 実施状況 |
|---|---|
| 1. テストタイプとカバレッジ要件を文書化したか | |
| 2. 使用ツールの最新安定版と LTS 状態を確認したか | |
| 3. CI/CD パイプラインにテストジョブを組み込んだか | |
| 4. ライセンスリスク（商用利用制限・サポート）を評価したか | |
| 5. 負荷テストシナリオと目標 SLA を定義したか | |
| 6. 小規模パイロットで実行時間・安定性指標を測定したか | |
| 7. Pact Broker（または同等）で契約管理基盤を構築したか | |
| 8. テスト結果のレポート／アラート設定を完了したか |
このチェックリストを GitHub リポジトリの
README.mdに貼り付け、プルリクエスト時に自動でタスクが作成されるようにすると、抜け漏れ防止に効果的です。
まとめ
- マイクロサービスはユニット・統合・契約・負荷の 4 種類（実務上は「テスト対象範囲」も含めて 5）を組み合わせることで、安定稼働が保証されます。
- 最新の JUnit、Mockito、Spring Test、Testcontainers、Pact JVM、Karate といったツールは、コード例とともに CI/CD・Kubernetes 環境へシームレスに組み込める ことが最大の強みです。
- 当社（Acme Cloud）提供のマネージド環境を活用すれば、インフラ構築コストなしで テスト基盤全体を即時利用開始 でき、開発サイクルの短縮と品質向上が同時に実現します。
ぜひ本稿の手順・比較表・チェックリストを活用し、貴社プロジェクトに最適なマイクロサービステスト戦略を構築してください。