api-contract-testing について
api-contract-testingは、APIの利用側と提供側の取り決めを、完全な統合テストに頼らず検証するスキルです。契約やスキーマの検証に加え、API変更の互換性を保つための実践方法を扱います。
主な機能
- 01利用側と提供側の契約テスト
- 02リクエストとレスポンスの検証
- 03OpenAPIとJSON Schemaの検証
- 04PactとPostmanのリファレンスガイド
- 05契約のバージョン管理とCIの指針
活用シーン
- 01マイクロサービス間通信のテスト
- 02破壊的なAPI変更の検出
- 03後方互換性の確認
- 04サードパーティAPI契約の検証
インストール
コマンドをコピーしてターミナルで実行します。
$
npx skills add https:/ / github.com/ aj-geddes/ useful-ai-prompts --skill api-contract-testingインストール後、Claude Code で/api-contract-testingを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
references/contract-testing-with-postman.mdjson-schema-validation.mdopenapi-schema-validation.mdpact-broker-integration.mdpact-for-consumer-driven-contracts.mdrest-assured-for-java.mdscripts/scaffold-tests.shtemplates/test-template.js詳細
API コントラクトテスト
目次
概要
コントラクトテストでは、API がコンシューマーとプロバイダー間のコントラクトを遵守しているかを検証します。完全な統合テストを実施しなくても、サービスの変更によって依存するコンシューマーが破損しないことを確認できます。コントラクトテストでは、リクエスト/レスポンスの形式、データ型、API の動作を個別に検証します。
使用する場面
- マイクロサービス間の通信をテストする
- API の互換性を損なう変更を防ぐ
- API のバージョン管理を検証する
- コンシューマーとプロバイダー間のコントラクトをテストする
- 後方互換性を確保する
- OpenAPI/Swagger 仕様を検証する
- サードパーティ API との統合をテストする
- CI でコントラクト違反を検出する
クイックスタート
最小限の実行例:
// tests/pact/user-service.pact.test.ts
import { PactV3, MatchersV3 } from "@pact-foundation/pact";
import { UserService } from "../../src/services/UserService";
const { like, eachLike, iso8601DateTimeWithMillis } = MatchersV3;
const provider = new PactV3({
consumer: "OrderService",
provider: "UserService",
port: 1234,
dir: "./pacts",
});
describe("User Service Contract", () => {
const userService = new UserService("http://localhost:1234");
describe("GET /users/:id", () => {
test("returns user when found", async () => {
await provider
.given("user with ID 123 exists")
.uponReceiving("a request for user 123")
.withRequest({
method: "GET",
path: "/users/123",
headers: {
// ... (see reference guides for full implementation)
リファレンスガイド
詳細な実装は references/ ディレクトリにあります:
| ガイド | 内容 |
|---|---|
| コンシューマー主導のコントラクトに対応する Pact | コンシューマー主導のコントラクトに対応する Pact |
| OpenAPI スキーマの検証 | OpenAPI スキーマの検証 |
| JSON Schema の検証 | JSON Schema の検証 |
| Java 向け REST Assured | Java 向け REST Assured |
| Postman を使ったコントラクトテスト | Postman を使ったコントラクトテスト |
| Pact Broker の統合 | Pact Broker の統合 |
ベストプラクティス
✅ 推奨事項
- コンシューマーの視点からコントラクトをテストする
- 柔軟に照合するためにマッチャーを使用する
- 特定の値ではなく、スキーマ構造を検証する
- コントラクトをバージョン管理する
- エラーレスポンスをテストする
- コントラクトの共有に Pact broker を使用する
- CI でコントラクトテストを実行する
- 後方互換性をテストする
❌ 禁止事項
- コントラクトテストでビジネスロジックをテストする
- コントラクトに特定の値をハードコードする
- エラーシナリオを省略する
- コントラクトテストで UI をテストする
- コントラクトのバージョン管理を無視する
- コントラクトを検証せずにデプロイする
- 実装の詳細をテストする
- コントラクトテストをモックする
コメント
Markdown 対応