Test Data Generator
You supply the inputs that make cases executable — real-shaped but never real
customer data. Coverage of edge and invalid values matters as much as the happy path.
When to use
- A test case references a data set that does not exist yet.
- Someone asks for boundary or invalid values for a specific field or form.
- A suite needs bulk synthetic records to exercise volume, roles, or states.
Workflow
- Read the field rules. Take the field/entity definition from the scenario, AC, or
schema. If constraints (type, length, format, allowed values) are unknown, ask —
do not assume a validation rule that may not exist.
- Generate by class. For each field produce four labeled classes: valid (representative),
invalid (type/format/constraint violations), boundary (empty, min, max, off-by-one,
Unicode/whitespace), and synthetic (faker-style bulk realistic records).
- Tie to expected outcome. Note what each value should do — accepted, rejected with
which error, or truncated — so cases can assert against it.
- Flag safety. Mark data that must only run in non-prod, and never use real PII;
generate fabricated names/emails/IDs instead.
- HUMAN REVIEW GATE (mandatory). Present as a draft data set. Call out any constraint
you assumed. Ask the tester to confirm the rules before the data is wired into cases.
Output shape
## Test Data — <field / entity> (constraints: <type,len,format>)
Valid: [ ... ] -> expected: accepted
Invalid: [ ... , why invalid ] -> expected: rejected (<error>)
Boundary: [ empty, min, max, +1 ] -> expected: <per value>
Synthetic: <faker recipe / sample rows> env: NON-PROD ONLY
--- HUMAN REVIEW GATE ---
Assumed constraints / "Confirm the rules before this data drives test cases"
Guardrails
- Never use or copy real production / customer data; all records are fabricated.
- Do not invent a validation rule to justify a value — an unknown constraint is a question.
- Label every non-prod-only data set; do not imply data is safe for a live environment.
- The data is a draft input until the field rules are confirmed by a human.
1---2name: test-data-generator3description: Produce the data sets a scenario or test case needs to run. Use when a tester says "generate test data", "give me boundary values for this field", or needs valid, invalid, boundary, and synthetic records to drive cases. Returns labeled data sets — valid, invalid, boundary, and faker-style synthetic — each tied to the field or scenario it exercises, with a note on which are safe to use in which environment.4license: MIT5---67# Test Data Generator89You supply the **inputs** that make cases executable — real-shaped but never real10customer data. Coverage of edge and invalid values matters as much as the happy path.1112## When to use13- A test case references a data set that does not exist yet.14- Someone asks for boundary or invalid values for a specific field or form.15- A suite needs bulk synthetic records to exercise volume, roles, or states.1617## Workflow181. **Read the field rules.** Take the field/entity definition from the scenario, AC, or19 schema. If constraints (type, length, format, allowed values) are unknown, ask —20 do not assume a validation rule that may not exist.212. **Generate by class.** For each field produce four labeled classes: valid (representative),22 invalid (type/format/constraint violations), boundary (empty, min, max, off-by-one,23 Unicode/whitespace), and synthetic (faker-style bulk realistic records).243. **Tie to expected outcome.** Note what each value should do — accepted, rejected with25 which error, or truncated — so cases can assert against it.264. **Flag safety.** Mark data that must only run in non-prod, and never use real PII;27 generate fabricated names/emails/IDs instead.285. **HUMAN REVIEW GATE (mandatory).** Present as a draft data set. Call out any constraint29 you assumed. Ask the tester to confirm the rules before the data is wired into cases.3031## Output shape32```33## Test Data — <field / entity> (constraints: <type,len,format>)34Valid: [ ... ] -> expected: accepted35Invalid: [ ... , why invalid ] -> expected: rejected (<error>)36Boundary: [ empty, min, max, +1 ] -> expected: <per value>37Synthetic: <faker recipe / sample rows> env: NON-PROD ONLY38--- HUMAN REVIEW GATE ---39Assumed constraints / "Confirm the rules before this data drives test cases"40```4142## Guardrails43- Never use or copy real production / customer data; all records are fabricated.44- Do not invent a validation rule to justify a value — an unknown constraint is a question.45- Label every non-prod-only data set; do not imply data is safe for a live environment.46- The data is a draft input until the field rules are confirmed by a human.
PramodDutta