test-data-factory·codegen·active

Test Data Factory

Synthesizes realistic test data — names, addresses, payment cards, medical records, account numbers — with deterministic seeds and PII safety.

EVANtrigger · agent

Test Data Factory

Synthesizes realistic test data — names, addresses, payment cards, medical records, account numbers — with deterministic seeds and PII safety guarantees.

When this skill fires

·A scenario or step definition needs sample data that wasn't provided in the spec

·An engineer calls Factory.user(), Factory.payment() etc. directly in a test

·API Test Generator needs request bodies for endpoint coverage

Why realistic > placeholder

→Realistic data exposes bugs that placeholder data hides. "O'Brien" catches quote escaping; "test" doesn't. "4242 4242 4242 4242" exercises a real Luhn-valid card path; "1234" doesn't.

The factory's job is to generate data that looks like production without being production.

Determinism

Every call takes an optional seed. Same seed → same output, every run, every machine. This means:

·Tests that depend on specific values are reproducible

·Snapshot tests don't churn from random data

·Failures are easier to debug because the data is consistent

If no seed is passed, the factory derives one from the test name + scenario tag — so re-runs of the same test get the same data, but different tests get different data.

PII safety

The factory's catalog is hand-curated to ensure:

·Names — drawn from public lists with no link to real individuals

·Emails — always on @nexaq.io or other reserved-for-testing domains, never @gmail.com etc.

·Addresses — composed from real postal formats but with fictitious street/city combinations

·Phone numbers — use the +1-555-01XX block (reserved for fiction)

·Credit cards — Luhn-valid but in test-card ranges accepted only by test gateways

·SSNs / national IDs — formatted correctly but in invalid ranges (e.g. SSN 000-00-XXXX)

→The factory will refuse to generate output that could plausibly be a real person's data. If a test needs that, the engineer must supply it explicitly with a clear annotation.

Domain modules

·Factory.user(opts?) — name, email, dob, locale

·Factory.payment(opts?) — card, billing address, currency

·Factory.medical(opts?) — patient ID, MRN, diagnosis code (ICD-10)

·Factory.financial(opts?) — account number, routing number, transaction

·Factory.address(opts?) — locale-aware postal formatting

What it produces

Plain TypeScript objects with the requested fields. No magic — they're trivial to inspect, override, or extend in the test itself.

Related · codegen

Step Definition Generator

step-def-generator

Converts Gherkin steps into Cucumber/TypeScript step definitions. Wires parameters, expression types, and shared world state automatically.

Page Object Generator

page-object-generator

Inspects DOM (live or via spec) and emits typed Page Objects with stable selectors and high-level actions. Enforces single-responsibility per object.

Locator Strategist

locator-strategist

Picks the most stable selector for a target element — role-based first, label-based next, test-id last. Avoids brittle CSS class chains.

API Test Generator

api-test-generator

Reads OpenAPI / GraphQL schemas and emits contract + integration tests. Handles auth, pagination, idempotency, and rate-limit assertions.

Assertion Expander

assertion-expander

Augments thin Gherkin Then-clauses with additional assertions: response codes, side-effects, audit log entries, downstream events.

Framework Adapter

framework-adapter

Same Gherkin spec → Playwright, Cypress, WebdriverIO, or Selenium output. Lets teams adopt the squad without re-platforming existing automation.