api-testinglisted

# API Testing Patterns API testing verifies contracts and behavior from the consumer perspective — correct responses, proper error handling, acceptable performance. Focus on what matters to consumers, not implementation details. ## When to use - Testing REST or GraphQL APIs - Validating microservice contracts - Designing API test strategies - Preventing breaking API changes - Triggers on "test API", "contract testing", "integration test", "API 测试", "接口测试", "契约测试" **Not for:** generating test scaffolds for non-API code (use `test-generation`); browser/E2E flows (use `e2e-testing`); the TDD loop itself (use `tdd`). ## Steps ### 1. Identify the testing level | Level | Purpose | Dependencies | Speed | |-------|---------|--------------|-------| | Contract | Provider-consumer agreement | None | Fast | | Component | API in isolation | Mocked external deps | Fast | | Integration | Real dependencies | Database, services | Slower | ### 2. Test the contract, not implementation Test from the consumer perspective using schema validation, not exact values. Consumers depend on the contract (status codes, response shape); they don't care about internal structure. **Pattern — Consumer-Driven Contracts:** schema validation against the contract (status codes, response shape), not exact values — code example in [references/templates/api-test-scaffold.md](references/templates/api-test-scaffold.md). Use **Pact** or **Spring Cloud Contract** for consumer-driven contract testing in microse