Test Data Generation
Produces realistic-looking, safe, varied test data aligned to a field spec or existing test case, ready to paste into a form, API call, or database seed script.
Process
- Get the shape first. Identify the fields, types, constraints (required/optional, length limits, formats, allowed values/enums, relationships between fields). If given a schema, API spec, or existing test case, extract constraints from it rather than guessing. If constraints are unclear, ask rather than invent limits that don't match the real system.
- Generate across these value classes for each field, not just happy-path values — this is Equivalence Partitioning and Boundary Value Analysis applied to data generation (see the
test-case-design skill's references/design-techniques.md for the underlying definitions):
- Valid — typical realistic values
- Valid boundary — min length/value, max length/value, exactly at any stated limit
- Invalid — wrong type, over/under limit, missing when required, malformed format
- Special characters — unicode, emoji, SQL/script-injection-shaped strings (for validation testing, not actual exploitation), whitespace-only
- Null/empty — explicit null vs empty string vs field omitted, where the system distinguishes them
- Keep referential integrity — if generating related entities (e.g. orders referencing customers), make sure foreign keys/IDs are internally consistent across the dataset unless the point is to test a broken reference.
- Never use real PII. All names, emails, phone numbers, addresses, and IDs must be synthetic. Use obviously-fake patterns (e.g.
test.user+N@example.com) so generated data can never be mistaken for real customer records downstream.
- Match the requested volume and format exactly — if asked for 50 rows, produce 50, not "here's a pattern, extrapolate."
Output format
Default to a markdown table for small sets (under ~15 rows) or when the user will read it directly; switch to CSV, JSON array, or SQL INSERT statements for larger sets or when the destination is stated. Always label which value class each row represents when the set mixes valid/invalid/boundary data, so it's clear which rows should pass vs fail validation.
See references/examples.md for a worked example covering all value classes for a simple form.
What not to do
- Don't generate real or real-looking PII, even for "realistic" test data — synthetic only.
- Don't silently skip invalid/boundary rows because they're harder to construct — that's usually the coverage that matters most.
- Don't invent constraints (e.g. a max length) that weren't stated or derivable from a schema — ask instead.
1---2name: test-data-generation3description: Generate sample/test datasets (valid, invalid, and boundary values) for a field, entity, or API payload, in CSV, JSON, or SQL insert format. Always use this skill when asked to generate test data, create fixtures, produce sample records, or build seed data for testing — even when phrased casually (e.g. "give me some sample users for this form", "I need dummy orders to test with", "generate 50 rows for the customers table"). Never use real customer/PII data — always synthetic.4---56# Test Data Generation78Produces realistic-looking, safe, varied test data aligned to a field spec or existing test case, ready to paste into a form, API call, or database seed script.910## Process11121. **Get the shape first.** Identify the fields, types, constraints (required/optional, length limits, formats, allowed values/enums, relationships between fields). If given a schema, API spec, or existing test case, extract constraints from it rather than guessing. If constraints are unclear, ask rather than invent limits that don't match the real system.132. **Generate across these value classes** for each field, not just happy-path values — this is Equivalence Partitioning and Boundary Value Analysis applied to data generation (see the `test-case-design` skill's `references/design-techniques.md` for the underlying definitions):14 - Valid — typical realistic values15 - Valid boundary — min length/value, max length/value, exactly at any stated limit16 - Invalid — wrong type, over/under limit, missing when required, malformed format17 - Special characters — unicode, emoji, SQL/script-injection-shaped strings (for validation testing, not actual exploitation), whitespace-only18 - Null/empty — explicit null vs empty string vs field omitted, where the system distinguishes them193. **Keep referential integrity** — if generating related entities (e.g. orders referencing customers), make sure foreign keys/IDs are internally consistent across the dataset unless the point is to test a broken reference.204. **Never use real PII.** All names, emails, phone numbers, addresses, and IDs must be synthetic. Use obviously-fake patterns (e.g. `test.user+N@example.com`) so generated data can never be mistaken for real customer records downstream.215. **Match the requested volume and format exactly** — if asked for 50 rows, produce 50, not "here's a pattern, extrapolate."2223## Output format2425Default to a markdown table for small sets (under ~15 rows) or when the user will read it directly; switch to CSV, JSON array, or SQL `INSERT` statements for larger sets or when the destination is stated. Always label which value class each row represents when the set mixes valid/invalid/boundary data, so it's clear which rows should pass vs fail validation.2627See `references/examples.md` for a worked example covering all value classes for a simple form.2829## What not to do30- Don't generate real or real-looking PII, even for "realistic" test data — synthetic only.31- Don't silently skip invalid/boundary rows because they're harder to construct — that's usually the coverage that matters most.32- Don't invent constraints (e.g. a max length) that weren't stated or derivable from a schema — ask instead.
santoshhundekar-qa