← ClaudeAtlas

test-apilisted

Playwright API testing best practices. Use when writing REST API tests with Playwright. Enforces Zod schema validation, client/fixture separation, and contract testing.
lgtm-hq/ai-skills · ★ 0 · Testing & QA · score 68
Install: claude install-skill lgtm-hq/ai-skills
# Playwright API Testing Write API tests using Playwright's built-in HTTP client. ## Project Structure ```text tests/ ├── specs/ # Test files organized by feature/domain ├── fixtures/ # Playwright fixtures (lifecycle + wiring) ├── clients/ # HTTP client logic (endpoints, methods) ├── schemas/ # Zod schemas (source of truth for types) ├── constants/ # Test data, business rules └── utils/ # Shared utilities ``` ## Schema Validation with Zod ### Use `z.strictObject()` for Contract Testing Catches unexpected extra properties from the API: ```typescript // GOOD: Fails if API returns extra fields export const UserSchema = z.strictObject({ id: z.string().uuid(), email: z.string().email(), createdAt: z.string(), }); // BAD: Silently ignores extra fields export const UserSchema = z.object({ ... }); ``` ### Derive Types from Schemas Single source of truth - never maintain separate type definitions: ```typescript // GOOD: Types derived from schemas export const UserSchema = z.strictObject({ ... }); export type User = z.infer<typeof UserSchema>; // BAD: Duplicate definitions that can drift apart interface User { ... } // in types.ts const UserSchema = z.object({ ... }) // in schemas.ts ``` ### Actually Validate Responses Use `schema.parse()` for runtime validation, not just type assertions: ```typescript // GOOD: Runtime validation const body = await response.json(); const user = UserResponseSchema.parse(body); // B