Build a QA fixture you can reproduce and review

Try the reviewed example

Open this exact schema in the generator

• qa-users-v1.schema.json
• qa-users-v1.json

These are synthetic examples. Record the engine version, schema and seed together. Checksums and row counts are in the example manifest. Review the output before importing it into a disposable test environment.

Watch the browser workflow

Silent walkthrough: open the saved schema, inspect its fields, choose the output format and start the download. The recording demonstrates browser generation and export; follow the written instructions below for the application or database steps.

Generate three users before generating thousands

Open the test data generator, add id as Row Number, name as Full Name and email as Email Address. Select JSON, set three rows and use the seed qa-demo-v1. Download the result and check that each property matches the API response your application expects. No account is required for this browser workflow.

If you use the repository checkout described in the CLI guide, the equivalent command is:

node cli/bin/fundata.js generate --field id:row_number --field name:full_name --field email:email_address --rows 3 --seed qa-demo-v1 --format json --out users.json

Keep the reviewed file in tests/fixtures/users.json. Record the schema, seed and repository revision if you need to regenerate it later. Seeded output is tied to engine and dataset versions; keeping the exported file preserves the exact fixture bytes.

Assert the response contract before the screen

This Playwright example assumes that your application requests /api/users and renders one element with data-testid="user-row" per user. Adjust both to your application's contract:

import { test, expect } from '@playwright/test';
import { readFileSync } from 'node:fs';
const users = JSON.parse(readFileSync('tests/fixtures/users.json', 'utf8'));

test('shows the supplied users', async ({ page }) => {
  await page.route('**/api/users', route =>
    route.fulfill({ status: 200, json: users })
  );
  await page.goto('/users');
  await expect(page.getByTestId('user-row')).toHaveCount(users.length);
});

For pagination, filters or a wrapped response such as {data: users}, make the mock implement that contract rather than assuming an array is sufficient. The Playwright guide covers more fixture patterns; the Cypress guide shows the corresponding workflow.

Separate realistic rows from deliberate failures

A generated list of plausible users does not prove validation coverage. Maintain a small named case table for an empty email, malformed email, Unicode name, missing optional property and a server error. An empty string, a JSON null and an absent key are three different cases. The generator's Blank % creates nulls in JSON; it does not remove the property.

Test an empty response and a failed response independently of your happy-path fixture. Avoid asserting that every generated value is accepted by a production validator: regional identity fixtures and deliberately invalid phone numbers have documented limits. Read the methodology and the QA test-data guide before choosing fields.

Review checklist and next step

• The mock shape, property names and status code match the endpoint.
• Dates have explicit fixed bounds if regeneration must be stable over time.
• The fixture contains the minimum rows needed to explain the assertion.
• The exported file, schema, seed and engine revision are recorded together.
• Failure cases are explicit and have readable names.

Build a JSON fixture, download an existing sample JSON dataset, or connect the local engine through MCP.

Last updated 16 October 2026