unit-test-wiremock-rest-api
WireMockを使用して外部REST APIのユニットテストを行うためのパターンを提供します。APIレスポンスのスタブ化、リクエスト詳細の検証、障害(タイムアウト、4xx/5xxエラー)のシミュレーション、実際のネットワーク通信なしでのHTTPクライアント動作の確認が可能です。外部APIとのサービス統合テストやHTTPエンドポイントのモック化が必要な場合に活用してください。
description の原文を見る
Provides patterns for unit testing external REST APIs using WireMock. Stubs API responses, verifies request details, simulates failures (timeouts, 4xx/5xx errors), and validates HTTP client behavior without real network calls. Use when testing service integrations with external APIs or mocking HTTP endpoints.
SKILL.md 本文
WireMockを使用したREST APIのユニットテスト
概要
WireMockを使用した外部REST API統合テストのパターン:レスポンスのスタブ化、リクエストの検証、エラーシナリオ、ネットワーク依存なしの高速テスト。
使用時機
- 外部REST APIを呼び出すサービスのテスト
- 予測可能なテスト動作のためのHTTPレスポンスのスタブ化
- エラーシナリオのテスト(タイムアウト、5xxエラー、不正なレスポンス)
- リクエスト詳細の検証(ヘッダー、クエリパラメータ、リクエストボディ)
実装手順
- 依存関係を追加:テストスコープのWireMock(Maven/Gradle)
- 拡張を登録:
dynamicPort()で@RegisterExtension WireMockExtensionを設定 - クライアントを構成:
wireMock.getRuntimeInfo().getHttpBaseUrl()をベースURLとして使用 - レスポンスをスタブ化:
stubFor()でリクエストマッチング(URL、ヘッダー、ボディ)を指定 - 実行と検証:サービスメソッドを呼び出し、AssertJで結果を検証
- リクエストを検証:
verify()でAPIの正しい使用を確認
スタブが一致しない場合:URLエンコーディング、ヘッダー名を確認し、クエリパラメータにurlEqualToを使用してください。
テストがハング状態になる場合:HTTPクライアントにコネクションタイムアウトを設定し、withFixedDelay()でタイムアウトシミュレーションを行ってください。
ポート競合がある場合:常にwireMockConfig().dynamicPort()を使用してください。
例
Maven依存関係
<dependency>
<groupId>org.wiremock</groupId>
<artifactId>wiremock</artifactId>
<version>3.4.1</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.assertj</groupId>
<artifactId>assertj-core</artifactId>
<scope>test</scope>
</dependency>
基本的なスタブ化と検証
import com.github.tomakehurst.wiremock.junit5.WireMockExtension;
import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.extension.RegisterExtension;
import static com.github.tomakehurst.wiremock.client.WireMock.*;
import static org.assertj.core.api.Assertions.assertThat;
class ExternalWeatherServiceTest {
@RegisterExtension
static WireMockExtension wireMock = WireMockExtension.newInstance()
.options(wireMockConfig().dynamicPort())
.build();
@Test
void shouldFetchWeatherDataFromExternalApi() {
wireMock.stubFor(get(urlEqualTo("/weather?city=London"))
.withHeader("Accept", containing("application/json"))
.willReturn(aResponse()
.withStatus(200)
.withHeader("Content-Type", "application/json")
.withBody("{\"city\":\"London\",\"temperature\":15,\"condition\":\"Cloudy\"}")));
String baseUrl = wireMock.getRuntimeInfo().getHttpBaseUrl();
WeatherApiClient client = new WeatherApiClient(baseUrl);
WeatherData weather = client.getWeather("London");
assertThat(weather.getCity()).isEqualTo("London");
assertThat(weather.getTemperature()).isEqualTo(15);
wireMock.verify(getRequestedFor(urlEqualTo("/weather?city=London"))
.withHeader("Accept", containing("application/json")));
}
}
エラーシナリオ、ボディ検証、タイムアウトシミュレーション、ステートフルテストについてはreferences/advanced-examples.mdを参照してください。
ベストプラクティス
- 動的ポート:並列テスト実行での競合を防止
- リクエストの検証:クライアントによるAPIの正しい使用を保証
- エラーのテスト:タイムアウト、4xx、5xxシナリオをカバー
- 限定的なスタブ:テストごとに1つの関心事
- 自動リセット:
@RegisterExtensionはテスト間でWireMockをリセット - 実際のAPIを呼び出さない:常にサードパーティエンドポイントをスタブ化
制約と警告
- 動的ポートが必須:固定ポートは並列実行での競合を引き起こす
- HTTPSテスト:TLS接続をテストする場合、WireMock TLS設定を構成
- スタブの優先度:より具体的なスタブが一般的なものより優先される
- パフォーマンス:WireMockはオーバーヘッドを追加します。より高速なテストのためクライアントレイヤーでモック化してください
- API変更:スタブを実際のAPIコントラクトと同期に保つ
参考資料
- WireMock Documentation
- WireMock Stubbing Guide
references/advanced-examples.md- エラーシナリオ、ボディ検証、タイムアウト
ライセンス: MIT(寛容ライセンスのため全文を引用しています) · 原本リポジトリ
詳細情報
- 作者
- giuseppe-trisciuoglio
- ライセンス
- MIT
- 最終更新
- 不明
Source: https://github.com/giuseppe-trisciuoglio/developer-kit / ライセンス: MIT
関連スキル
doubt-driven-development
重要な判断はすべて、本番環境への展開前に新しい視点から対抗的レビューを実施します。速度より正確性が重要な場合、不慣れなコードを扱う場合、本番環境・セキュリティに関わるロジック・取り消し不可の操作など影響度が高い場合、または後でバグを修正するよりも今検証する方が効率的な場合に活用してください。
apprun-skills
TypeScriptを使用したAppRunアプリケーションのMVU設計に関する総合的なガイダンスが得られます。コンポーネントパターン、イベントハンドリング、状態管理(非同期ジェネレータを含む)、パラメータと保護機能を備えたルーティング・ナビゲーション、vistestを使用したテストに対応しています。AppRunコンポーネントの設計・レビュー、ルートの配線、状態フローの管理、AppRunテストの作成時に活用してください。
desloppify
コードベースのヘルスチェックと技術負債の追跡ツールです。コード品質、技術負債、デッドコード、大規模ファイル、ゴッドクラス、重複関数、コードスメル、命名規則の問題、インポートサイクル、結合度の問題についてユーザーが質問した場合に使用してください。また、ヘルススコアの確認、次の改善項目の提案、クリーンアップ計画の作成をリクエストされた際にも対応します。29言語に対応しています。
debugging-and-error-recovery
テストが失敗したり、ビルドが壊れたり、動作が期待と異なったり、予期しないエラーが発生したりした場合に、体系的な根本原因デバッグをガイドします。推測ではなく、根本原因を見つけて修正するための体系的なアプローチが必要な場合に使用してください。
test-driven-development
テスト駆動開発により実装を進めます。ロジックの実装、バグの修正、動作の変更など、あらゆる場面で活用できます。コードが正常に動作することを証明する必要がある場合、バグ報告を受けた場合、既存機能を修正する予定がある場合に使用してください。
incremental-implementation
変更を段階的に実施します。複数のファイルに影響する機能や変更を実装する場合に使用してください。大量のコードを一度に書こうとしている場合や、タスクが一度では完結できないほど大きい場合に活用します。