🧬 Test Data Generation

Test Data Generation: Asking Claude for equivalence-partitioning test data is like asking a tailor for one garment per size category (XS/S/M/L/XL) instead of ordering one of ever

Asking Claude for equivalence-partitioning test data is like asking a tailor for one garment per size category (XS/S/M/L/XL) instead of ordering one of every possible measurement — the mechanism matches exactly: equivalence partitioning already reduces infinite possible inputs down to representative classes, and an LLM is excellent at instantiating "one believable example per class" once you name the classes, but it cannot invent the classes correctly if you don't specify the actual business rule (what counts as a "valid" range for THIS field). Here is the question worth sitting with: if Claude can generate a thousand fake ID-shaped numbers in a second, why is it still dangerous to grab 10 REAL customer records from production for a test instead? Because a real record carries real consequences if it leaks in a shared test environment or a bug-report screenshot, while a well-formed FAKE record that merely LOOKS valid (right digit count, right checksum shape) exercises the exact same code path with zero privacy exposure. Java comparison: this is the same reasoning behind the Java Faker library shipping in test scope only, generating Faker.name().fullName() instead of hardcoding a real employee's name into a unit test fixture. The QA stake: a test database seeded with real customer PII — even in a "test" environment — is a compliance incident waiting to be discovered during an audit, while one seeded with LLM- or Faker-generated look-alike data carries the same test coverage with zero regulatory exposure.

Boundary and Equivalence Data, On Demand

Name the equivalence classes and boundaries explicitly in the prompt — for example, "age field: valid 18-65, invalid below 18 and above 65, boundary exactly 18 and 65." Claude then generates one instance per class instead of guessing which boundaries matter for a field it has never seen before.

Reasoning: why not just use Java Faker for everything? Faker is deterministic, fast and battle-tested for GENERIC fields (names, addresses, emails) — reach for it on every automated CI run. Claude is better when the DATA SHAPE itself needs domain judgment your Faker call doesn't encode, like "generate 5 boundary-value rows for a discount field that behaves differently above 40% due to a specific business rule." Rule of thumb: Faker for volume and CI-speed, Claude for one-off DESIGN of which values matter before you wire them into Faker or a fixed dataset.

Step by Step: From Boundary Rule to Test Data

Valid/invalid equivalence classes and the exact boundary numbers are stated explicitly in the prompt.

Ask Claude to design

Instead of a random pile of numbers, one representative value per class is requested.

Pick the output format

JSON, CSV or SQL INSERT is specified — the result drops directly where you need it.

The output is scanned: is every value format-valid but clearly fake?

Faker for volume, Claude for design

Once the classes are confirmed, the bulk/CI version is generated with Faker; Claude stays for one-off design decisions.

Arrange the flow from a business rule to safe, boundary-aware test data in the correct order.