# Test Data Generation

> 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.

- Skill: `santoshhundekar-qa/test-data-generation` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add santoshhundekar-qa/test-data-generation`
- Raw SKILL.md: https://api.skillmd.com/api/skills/santoshhundekar-qa/test-data-generation/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Data & Analytics
- Author: santoshhundekar-qa (https://skillmd.com/u/santoshhundekar-qa)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/santoshhundekar-qa/test-data-generation

---


# 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

1. **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.
2. **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
3. **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.
4. **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.
5. **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.