API Testing (Playwright + REST Assured)
Comprehensive API testing skill covering both Playwright TypeScript (request fixture, Supertest, Zod) and Java (REST Assured, AssertJ, JSON Schema Validator).
When to Use This Skill
- Create API tests for REST or GraphQL endpoints
- Validate request/response schemas (Zod, JSON Schema)
- Test authentication flows (OAuth2, JWT, API keys, Bearer tokens)
- Verify error handling (400, 401, 403, 404, 409, 422, 500)
- Test pagination, filtering, sorting edge cases
- Validate idempotency for PUT/DELETE operations
- Contract testing between services
- Rate limiting validation
Do NOT Use For
- Browser-driven UI flows (use
playwright-e2e-testing for Playwright specs, or webapp-selenium-testing for Selenium)
- Live interactive browser sessions or snapshots (use
playwright-cli)
- Visual/layout regression (out of scope — no DOM)
- End-to-end journeys that must drive a real browser across pages
Prerequisites
| Stack |
Requirements |
| TypeScript |
Node.js 18+, @playwright/test or supertest, zod |
| Java |
Java 21+, REST Assured 5.x, AssertJ, Jackson, json-schema-validator |
Core Principles
- Schema validation on every response — never trust an unvalidated response
- Test all HTTP status codes — happy path AND error states
- Auth testing is mandatory — verify 401/403 for protected endpoints
- Data-driven — test with valid, invalid, boundary, and empty values
- Stateless where possible — each test cleans up or uses unique data
Quick Reference — Playwright
import { test, expect } from "@playwright/test";
test("GET /api/users returns 200 with valid schema", async ({ request }) => {
const response = await request.get("/api/users");
expect(response.ok()).toBeTruthy();
const body = await response.json();
expect(body).toMatchObject({ data: expect.any(Array) });
});
Quick Reference — REST Assured
import static io.restassured.RestAssured.*;
import static org.hamcrest.Matchers.*;
import java.util.List;
import org.junit.jupiter.api.DisplayName;
import org.junit.jupiter.api.Test;
@Test
@DisplayName("GET /api/users returns 200 with valid schema")
void getUsers() {
String token = "test-token";
given()
.header("Authorization", "Bearer " + token)
.when()
.get("/api/users")
.then()
.statusCode(200)
.body("data", is(instanceOf(List.class)))
.body("data.size()", greaterThan(0));
}
Red Flags
Stop and reconsider if you see any of these in generated API tests:
- Assertions only on status code with no body/schema validation — an unvalidated response hides contract drift.
- Hardcoded secrets/tokens committed to the test file — read from env or a secrets manager.
- Tests sharing mutable state with no cleanup — flaky and order-dependent.
- Skipping auth tests (no 401/403 assertions on protected endpoints) — security regression risk.
- No coverage of error states (only happy-path 200s) — error handling is untested.
References
| Document |
Content |
| REST API Patterns |
CRUD, pagination, filtering, error patterns |
| Playwright API Testing |
Request fixture, Supertest, TypeScript patterns |
| REST Assured Testing |
REST Assured, AssertJ, Java patterns |
| Schema Validation |
Zod (TS), JSON Schema (Java), strict vs loose |
| Contract Testing |
Request/response contracts, idempotency, versioning |
Templates
Scripts
Troubleshooting
| Issue |
Solution |
| 401 on authenticated endpoints |
Verify token is fresh; check expiry; re-authenticate |
| Flaky API tests |
Add retry logic; check for rate limiting; use unique test data |
| Schema validation too strict |
Use .passthrough() (Zod) or additionalProperties: true for flexible fields |
| Timeout on slow endpoints |
Increase timeout in request options; check for server load |
Verification
1---2name: api-testing3description: Test REST and GraphQL endpoint contracts using Playwright request fixture (TypeScript) or REST Assured (Java). Use for standalone API tests covering schemas, auth, status/error handling, pagination, idempotency, rate limits, or contract checks; not for browser E2E specs. Keywords: REST, GraphQL, API contract, schema validation, REST Assured.4license: Complete terms in LICENSE.txt5---67# API Testing (Playwright + REST Assured)89Comprehensive API testing skill covering both Playwright TypeScript (request fixture, Supertest, Zod) and Java (REST Assured, AssertJ, JSON Schema Validator).1011## When to Use This Skill1213- Create API tests for REST or GraphQL endpoints14- Validate request/response schemas (Zod, JSON Schema)15- Test authentication flows (OAuth2, JWT, API keys, Bearer tokens)16- Verify error handling (400, 401, 403, 404, 409, 422, 500)17- Test pagination, filtering, sorting edge cases18- Validate idempotency for PUT/DELETE operations19- Contract testing between services20- Rate limiting validation2122### Do NOT Use For2324- Browser-driven UI flows (use `playwright-e2e-testing` for Playwright specs, or `webapp-selenium-testing` for Selenium)25- Live interactive browser sessions or snapshots (use `playwright-cli`)26- Visual/layout regression (out of scope — no DOM)27- End-to-end journeys that must drive a real browser across pages2829## Prerequisites3031| Stack | Requirements |32| ---------- | --------------------------------------------------------------------- |33| TypeScript | Node.js 18+, `@playwright/test` or `supertest`, `zod` |34| Java | Java 21+, REST Assured 5.x, AssertJ, Jackson, `json-schema-validator` |3536## Core Principles37381. **Schema validation on every response** — never trust an unvalidated response392. **Test all HTTP status codes** — happy path AND error states403. **Auth testing is mandatory** — verify 401/403 for protected endpoints414. **Data-driven** — test with valid, invalid, boundary, and empty values425. **Stateless where possible** — each test cleans up or uses unique data4344## Quick Reference — Playwright4546```typescript47import { test, expect } from "@playwright/test";4849test("GET /api/users returns 200 with valid schema", async ({ request }) => {50 const response = await request.get("/api/users");51 expect(response.ok()).toBeTruthy();52 const body = await response.json();53 expect(body).toMatchObject({ data: expect.any(Array) });54});55```5657## Quick Reference — REST Assured5859```java60import static io.restassured.RestAssured.*;61import static org.hamcrest.Matchers.*;6263import java.util.List;6465import org.junit.jupiter.api.DisplayName;66import org.junit.jupiter.api.Test;6768@Test69@DisplayName("GET /api/users returns 200 with valid schema")70void getUsers() {71 String token = "test-token";7273 given()74 .header("Authorization", "Bearer " + token)75 .when()76 .get("/api/users")77 .then()78 .statusCode(200)79 .body("data", is(instanceOf(List.class)))80 .body("data.size()", greaterThan(0));81}82```838485---8687## Red Flags8889Stop and reconsider if you see any of these in generated API tests:9091- Assertions only on status code with no body/schema validation — an unvalidated response hides contract drift.92- Hardcoded secrets/tokens committed to the test file — read from env or a secrets manager.93- Tests sharing mutable state with no cleanup — flaky and order-dependent.94- Skipping auth tests (no 401/403 assertions on protected endpoints) — security regression risk.95- No coverage of error states (only happy-path 200s) — error handling is untested.9697---9899## References100101| Document | Content |102| ---------------------------------------------------------------- | --------------------------------------------------- |103| [REST API Patterns](./references/rest-api-patterns.md) | CRUD, pagination, filtering, error patterns |104| [Playwright API Testing](./references/playwright-api-testing.md) | Request fixture, Supertest, TypeScript patterns |105| [REST Assured Testing](./references/rest-assured-testing.md) | REST Assured, AssertJ, Java patterns |106| [Schema Validation](./references/schema-validation.md) | Zod (TS), JSON Schema (Java), strict vs loose |107| [Contract Testing](./references/contract-testing.md) | Request/response contracts, idempotency, versioning |108109## Templates110111- [Playwright API Spec](./templates/playwright-api-spec.ts) — starter test file for API testing112- [REST Assured Test](./templates/rest-assured-test.java) — starter Java test class113114## Scripts115116- [API Health Check](./scripts/api-health-check.sh) — validate API endpoints respond correctly117118## Troubleshooting119120| Issue | Solution |121| ------------------------------ | ------------------------------------------------------------------------------ |122| 401 on authenticated endpoints | Verify token is fresh; check expiry; re-authenticate |123| Flaky API tests | Add retry logic; check for rate limiting; use unique test data |124| Schema validation too strict | Use `.passthrough()` (Zod) or `additionalProperties: true` for flexible fields |125| Timeout on slow endpoints | Increase `timeout` in request options; check for server load |126127---128129## Verification130131- [ ] **Schema validation in place** — Every response validated against a schema (Zod or JSON Schema)132- [ ] **Authentication tested** — 401 returned for protected endpoints without valid credentials133- [ ] **Idempotency verified** — PUT/DELETE produce same result when called multiple times134- [ ] **Edge cases covered** — Empty payloads, invalid types, boundary values, SQL injection attempts