api-playwright-test-developer

API Playwright Test Developer

This skill defines the standard approach for writing and maintaining Playwright-based API tests. It is optimized for robust, repeatable automated validation of REST/GraphQL services, readable test design, and minimal flakiness.

When to Use

• API endpoint functional testing (status, schema, body values)
• Data-driven regression coverage across all environments
• Contract checks (OpenAPI/JSON Schema) for service evolution
• End-to-end test flows mixing UI and API interactions (hybrid tests)
• CI pipeline smoke tests and API health checks

Core Principles

1. Explicit setup/teardown
   • Use test.beforeEach and test.afterEach for consistent test state management (e.g., create/delete test data).
   • Clean up created test data in test.afterEach by default. Skip cleanup only temporarily when debugging a failure, and never commit that state.
   • Avoid shared mutable state across tests to prevent flakiness.
   • Use unique identifiers in test data to avoid collisions and ensure idempotency.
2. Single responsibility per test case
   • Each test should target one behavior (e.g., 200 vs 401, field validation, paginated listing).
   • Use descriptive test titles to clarify the intent and expected outcome.
   • For complex scenarios, break down into multiple focused tests rather than one large test with many assertions.
   • When testing e2e flows, consider using test.step to logically group related API calls and assertions within a single test case.
3. Assertions
   • Avoid brittle tests that rely on dynamic timestamps or ordering unless controlled.
   • Add descriptive messages to assertions for easier debugging.
   • Use soft assertions expect.soft for multiple checks in a single test without stopping at the first failure.
4. Clear data management
   • Use fixtures/config to store base URL, auth tokens, test payload templates.
   • Use factory functions to generate test data with unique identifiers.
   • Avoid hardcoding environment-specific values in tests; use environment variables or config files.
   • For complex data setup, consider using API calls in beforeEach to create necessary resources instead of relying on static test data.
5. Patterns and best practices
   • Use request fixture for API calls.
   • Use AAA pattern (Arrange-Act-Assert) for test structure.
   • Use builders or factories for constructing request payloads to improve readability and maintainability.
   • Use Simple Request Object Pattern to encapsulate API interactions and reduce duplication across tests.
   • Use test.describe to group related tests and share setup/teardown logic.