Sample JSON data

Typed, not stringly typed

The common failing of hand-written JSON fixtures is that everything ends up a string, so the fixture silently disagrees with the API it is standing in for. The JSON export emits each field as its natural type:

[
  {
    "id": 1,
    "name": "Elena Rossi",
    "email": "elena.rossi7@example.org",
    "age": 34,
    "balance": 1284.50,
    "is_active": true,
    "referred_by": null,
    "created_at": "2024-03-18T09:14:22Z"
  }
]

age is a number, is_active is a boolean, and referred_by is null because that field has a Blank % set. A frontend that does user.age > 18 behaves the same against this fixture as against the real endpoint — which is the entire point of a fixture.

Nested objects

Real API responses are rarely flat. Name a field with dots and the export nests it:

Field name              JSON output
------------------------------------------------
id                      "id": 1
address.city            "address": { "city": "Lyon",
address.country                       "country": "France" }
account.plan            "account": { "plan": "pro",
account.seats                        "seats": 12 }

That covers most response shapes without any post-processing. For anything more elaborate — a wrapping envelope, pagination metadata, an array inside each record — generate the array and reshape it in a couple of lines with jq or a script; the mock API guide shows the common envelope patterns.

One array or one object per line?

The JSON export gives you a single array, which is what a browser fetch, a fixture file and a mock server all expect. NDJSON gives you one object per line, which is what streaming tools want — jq without slurping, BigQuery loads, Elasticsearch bulk ingest, and anything that should not hold the whole file in memory. Same schema, different serializer.

Fixtures that survive a code review

Three things make generated JSON worth committing rather than regenerating:

• A seed. Byte-identical output every run means the fixture file has a stable diff, and a test can assert on data[0].email without a snapshot dance.
• Deliberate nulls. Set Blank % on every field the API declares optional. Most frontend crashes in this area come from a field the fixture always populated and the API sometimes does not.
• Enough rows to page. Twenty records will not reveal a broken pagination control. Generate past your page size.

Loading it into a mock server

# json-server: an instant REST API over the file
npx json-server --watch users.json --port 3001

# Node: import it in a test
const users = require('./fixtures/users.json');

# jq: check the shape before trusting it
jq '.[0] | keys' users.json
jq 'map(select(.is_active)) | length' users.json

Escaping and encoding

Output is UTF-8 and valid JSON, with quotes, backslashes and control characters escaped as the specification requires. Text fields deliberately include non-ASCII names, which is worth keeping — a fixture consisting only of ASCII will not tell you whether your pipeline mangles Yılmaz somewhere between the database and the browser.

Common questions

Related

• Mock API data guide — envelopes, response states and contract tests.
• Sample CSV files — the same schemas as flat files.
• NDJSON export — streaming-friendly output.
• Playwright test data — using JSON fixtures in a test suite.