test-data-conventions

Defines test data generation, resolution, and cleanup rules for Playwright end-to-end suites.

5|2|Updated May 19, 2026
One-click install
npx skills add https://github.com/civitas-cerebrum/achilles --skill test-data-conventions-civitas-cerebrum
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: test-data-conventions
Source: https://github.com/civitas-cerebrum/achilles/tree/main/skills/test-data-conventions
Command: npx skills add https://github.com/civitas-cerebrum/achilles --skill test-data-conventions-civitas-cerebrum

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? End-to-end test suites become flaky when tests hardcode current content, share accounts across parallel workers, or create records nothing cleans up. This Skill establishes a single doctrine for how tests relate to data — discovery of data sources, a two-strategy decision ladder, and twelve rules covering generation, cleanup, and feasibility gating. ## Core Features & Use Cases - Two-strategy decision ladder: Classifies every data dependency as either seed-your-own-data (programmatic generation with hook-based cleanup) or content-resilient handling (runtime resolution of declared requirements against the app's own source). - Twelve operational rules: Covers per-attempt unique data generation, three-class dependency-error taxonomy (premise/app-state/infra), worker-scoped account pools, hydration-safe form filling, and a data-feasibility composing gate. - Living test data plan: Maintains tests/e2e/docs/test-data-plan.md recording each dependency's current strategy, gaps, and a roadmap to an ideal test environment. - Use Case: When composing a signup or order-creation test, apply the ladder to decide whether to seed data via API, resolve content at runtime, or block the scenario — then record the outcome in the test data plan. ## Quick Start Apply the test data conventions to decide how the new checkout test should source, isolate, and clean up its data.

Frequently Asked Questions about test-data-conventions

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I handle test data in Playwright end-to-end tests?

Choose between two strategies per data dependency: seed your own data programmatically with unique per-attempt values and clean up in hooks, or declare content requirements and resolve them at runtime against the app's own source. Hardcoding current content is never a valid strategy.

Why do my tests fail only on retries?

Retry-only failures usually come from module-scope data generation. A retry re-runs the test body but not module scope, so the retried attempt reuses the first attempt's identity and collides with leftover state. Generate data inside the test body per attempt.

How do I prevent parallel test workers from sharing accounts?

Pool accounts per worker using an expression like accounts[test.info().workerIndex % accounts.length] with a pool at least as large as the worker count, or create a fresh user per worker. Shared accounts cause throttling that fails other workers on valid credentials.

When should a test skip versus fail on missing data?

Classify the dependency error first: premise failures (content cannot satisfy the requirement) are the only skippable class and must skip by name; app-state failures (broken rendering) and infra failures (transport errors) must fail. Misclassification produces false alarms or silently skipped regressions.

Can tests run against production or shared environments?

Side-effecting operations like real emails, registrations, or orders are gated on a declared test environment. On shared or production-like environments, exclude the scenario with a named annotation rather than running it once, and record the gap in the test data plan.