API Testing Patterns

<default_to_action> When testing APIs or designing API test strategy:

1. IDENTIFY testing level: contract, integration, or component
2. TEST the contract, not implementation (consumer perspective)
3. VALIDATE auth, input, errors, idempotency, concurrency
4. AUTOMATE in CI/CD with schema validation
5. MONITOR production APIs for contract drift

Quick Pattern Selection:

• Microservices → Consumer-driven contracts (Pact)
• REST APIs → CRUD + pagination + filtering tests
• GraphQL → Query validation + complexity limits
• External deps → Mock with component testing
• Performance → Load test critical endpoints

Critical Success Factors:

• APIs are contracts - test from consumer perspective
• Always test error scenarios, not just happy paths
• Version your API tests to prevent breaking changes </default_to_action>

Quick Reference Card

When to Use

• Testing REST or GraphQL APIs
• Validating microservice contracts
• Designing API test strategies
• Preventing breaking API changes

Testing Levels

Level	Purpose	Dependencies	Speed
Contract	Provider-consumer agreement	None	Fast
Component	API in isolation	Mocked	Fast
Integration	Real dependencies	Database, services	Slower

Critical Test Scenarios

Scenario	Must Test	Example
Auth	401/403 handling	Expired token, wrong user
Input	400 validation	Missing fields, wrong types
Errors	500 graceful handling	DB down, timeout
Idempotency	Duplicate prevention	Same idempotency key
Concurrency	Race conditions	Parallel checkout

Tools

• Contract: Pact, Spring Cloud Contract
• REST: Supertest, REST-assured, Playwright
• Load: k6, Artillery, JMeter