mcpField
7
702-technologies-wiremock

702-technologies-wiremock

github.com/jabrenaテスト・品質456301 回インストール1 日前に更新
リポジトリ

702-technologies-wiremock について

WireMock で HTTP 依存先をスタブ化し、安定した分離テストを行うためのスキルです。リクエスト照合や応答、呼び出し検証を扱い、フレームワーク固有の設定は別のスキルに委ねます。

主な機能

  1. 01テストごとのスタブ分離
  2. 02HTTP リクエスト照合
  3. 03応答と障害の設定
  4. 04動的ポートの扱い
  5. 05外部呼び出しの検証
  6. 06未照合リクエストの調査

活用シーン

  1. 01WireMock スタブの設計・レビュー
  2. 02共有スタブによるテスト不安定化の抑制
  3. 03外部 HTTP 呼び出しの検証
  4. 04未照合リクエストの調査

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/jabrena/plinth --skill 702-technologies-wiremock

インストール後、Claude Code で/702-technologies-wiremockを入力して読み込まれたか確認します。

同梱ファイルreferences/702-technologies-wiremock.md

詳細

WireMock のベストプラクティス

WireMock を効果的に活用し、HTTP 依存関係のスタブ化において、安定した、分離されたテストを実現できるようチームを支援します。

このスキルで扱う内容

  • スタブの分離：テストごとの登録、resetAll()、グローバルスタブの漏れの防止
  • リクエストのマッチング：メソッド、パス、ヘッダー、クエリ、ボディのパターン、および広範なパターンを使用できる場合
  • レスポンス：ステータス、ヘッダー、JSON/XML ボディ、bodyFileName／クラスパスのフィクスチャ、障害のシミュレーション（遅延、エラー）
  • 動的ポートと、テスト対象システムへのベース URL の引き渡し
  • 外部 HTTP 呼び出しの検証と、マッチしないリクエストのデバッグ
  • テストクラスの構成やエクステンションについて、フレームワーク統合テストのスキルへ明確に委任すること

対象範囲： ポータブルな WireMock の動作のみです。BaseIntegrationTest、WireMockExtension、スタック固有の統合テストについては、@132-java-testing-integration-testing、@322-frameworks-spring-boot-testing-integration-tests、@422-frameworks-quarkus-testing-integration-tests、または@522-frameworks-micronaut-testing-integration-testsを使用してください。OpenAPI コントラクトの品質については、@701-technologies-openapiを使用してください。

制約

ユーザーがフレームワーク統合を明示的に求めない限り、推奨事項は WireMock と HTTP スタブの範囲にとどめてください。このリポジトリの XML ソースを編集した後は、スキルを再生成し、ビルドを検証してください。

  • 必須：同じ変更セット内で Java または Maven の変更を提案する前に、./mvnw compileまたはmvn compileを実行してください
  • フレームワーク：@SpringBootTest／@QuarkusTest／@MicronautTestとエクステンションの設定は、@132-java-testing-integration-testingまたは該当する322／422／522の統合テストスキルに委任してください
  • コントラクト：OpenAPI ドキュメントの構造とリンティングは、@701-technologies-openapiに委任してください
  • 検証：変更を採用する前に、./mvnw clean verifyまたはmvn clean verifyを実行してください
  • エッジケース：ユーザーの目的が曖昧な場合は、ファイルの編集やプロジェクト全体に関わるコマンドの実行を開始する前に作業を止め、明確化のための質問をしてください
  • エッジケース：必要なコンテキスト、ファイル、認証情報、またはツールが不足している場合は、阻害要因を明示して報告し、セットアップを進めるか、代替の案内を行うかを確認してください
  • エッジケース：依頼された変更がプロジェクトの制約や安全上の境界と矛盾する場合は、その矛盾を説明し、どのトレードオフを優先するかユーザーに確認してください

このスキルを使用する場面

  • WireMock のスタブ（JSON マッピングまたは Java DSL）の設計やレビュー
  • HTTP モックのリクエストマッチング、分離、またはリセット戦略の改善
  • WireMock サーバーへの外部 HTTP 呼び出しの検証の追加や修正
  • WireMock またはマッチしないリクエストのジャーナルに関わる不安定なテストのデバッグ
  • 安定したフィクスチャと動的ポートを使った、テストでの外部 HTTP API のスタブ化

ワークフロー

  1. リファレンスを読み、プロジェクトのコンテキストを評価する

変更を提案する前に、references/702-technologies-wiremock.mdを読み、現在の API／コンテキストの成果物を確認してください。

  1. 対象範囲を把握し、改善対象を決定する

求められている結果と制約を特定し、適用する変更を必要最小限の安全な範囲に絞ってください。

  1. 技術に沿った変更を適用する

リファレンスのパターンとプロジェクトの規約に従って、成果物を実装またはリファクタリングしてください。

  1. 検証を実行し、結果を報告する

適切なチェックを実行し、変更内容、検証内容、今後必要な作業を要約してください。

リファレンス

詳細なガイダンス、例、制約については、references/702-technologies-wiremock.mdを参照してください。

コメント

Markdown 対応