Generate Test Data Fixtures from a Schema
Reads a data schema (JSON Schema, TypeScript type, or table description) and returns four explicit fixture groups — happy path, boundary, invalid, and edge cases. Edge group must include Unicode, RTL, emoji, and injection payloads. Output is a ready-to-import JSON file.
When to use it
- You're seeding a test database and need realistic + adversarial fixtures.
- You're writing parameterized tests and need fixture arrays grouped by intent.
- You're testing input validation and want consistent boundary/edge coverage across fields.
- You're auditing existing test data for missing edge cases (Unicode, injection, max length).
The prompt
XML-tagged — best for Claude 4.x
<role>
You are a test data engineer who has been burned by Unicode and injection edge cases more times than you'd like to admit. You generate fixtures that find bugs in input handling, not fixtures that pass.
</role>
<context>
Fixtures are consumed by parameterized tests. They live in version control as JSON. Each fixture file has four named arrays: happy, boundary, invalid, edge. Edge MUST include Unicode (BMP + supplementary), RTL languages (Arabic / Hebrew), emoji, zero-width chars, and at least one injection payload per string field.
</context>
<task>
For the schema I provide, generate a fixtures JSON with four arrays:
- happy: 3-5 valid representative records
- boundary: one record per numeric/length constraint at the boundary (max length, min length, just-below-min, just-above-max)
- invalid: 3-5 records that should fail validation, each violating a different rule
- edge: 5-8 records including Unicode (multiple scripts), RTL, emoji, zero-width, null, empty string, max-length string at the boundary, and an injection payload per string field
</task>
<input>
Schema (JSON Schema, TS type, or table): {schema}
Additional constraints: {constraints}
</input>
<constraints>
- Output is a single valid JSON object with four named arrays.
- Every record must conform to the field shape (so they can be deserialized) — invalid means rule-violation, not malformed JSON.
- Include a 'why' field on every invalid and edge record explaining what rule it tests.
- Use realistic-looking values, not "foo" / "bar".
- For injection payloads, include at minimum: SQL ('; DROP TABLE x;--), XSS (<script>alert(1)</script>), template ({{7*7}}).
</constraints>
<output_format>
A JSON code block with the fixtures object, followed by a 1-2 sentence "Notes" paragraph listing any fields you couldn't generate edge cases for and why.
</output_format>
Think through what edge cases this schema's field types are vulnerable to before writing.Example
Common pitfalls
- Edge group ships without Unicode or injection because the model defaults to 'safe' fixtures — constraints must force them.
- Boundary group misses just-below-min and just-above-max if you don't ask for them per constraint.
- Model produces fixtures with `foo` / `bar` values — unrealistic data hides bugs that surface only with real-looking strings.
- Invalid records sometimes break JSON shape (extra/missing fields) — should fail validation, not deserialization. Re-prompt if so.
Tips
- If the schema has 10+ fields, split into two runs (group by entity) to keep boundary coverage thorough.
- Append the resulting fixtures to a `*.fixtures.json` file with timestamp; let your tests load them — easy to extend.
- For database-seeded tests, also generate Foreign Key relationships explicitly (separate prompt run per relationship).
- Re-run the prompt when the schema changes; diff old vs new fixtures to find which test cases need refresh.
FAQ
A fixture is static data committed to the repo. A factory generates data at test time via code (`createUser({age: 25})`). Use fixtures for representative + edge cases you care about catching every run. Use factories for combinatorial variation. Most projects need both.
Related prompts
Boundary Value & Equivalence Partition Generator
Reads field constraints (min/max/length/format) and returns boundary and equivalence-partition cases for each — values just inside, on, and just outside the boundary — with technique labels (BVA or EP) per case.
Open →Generate Test Cases from Requirements
Given one requirement, the model returns a structured suite of 8-10 test cases — ID, title, preconditions, steps, expected result, priority, and the design technique that generated each case — covering happy path, negative scenarios, boundary values, equivalence partitions, and edge cases.
Open →Create API Test Suite from OpenAPI Spec
Reads an OpenAPI 3.x specification and returns an API test suite that validates response schemas per documented status code, covers authentication, pagination, filtering, and the standard error responses (400, 401, 403, 404, 429, 500). Output is framework-agnostic plan plus Playwright APIRequestContext skeleton.
Open →Create OWASP Top 10 Test Scenarios
For each OWASP Top 10 (2025) category (A01-A10), returns 3-5 concrete test cases with payloads, recommended tools, expected secure behavior, and remediation guidance tailored to the target application.
Open →