How to Generate UUID v4 Values for Test Data

A test fixture can fail even when every record looks correct: a task may point to a project ID that was regenerated after the task was created. Generating identifiers is only the first step. You also need to preserve their relationships and keep repeatable tests repeatable.

This example builds one fictional project with two tasks. Generate three UUID v4 values, assign each a clear role, and save the finished fixture before importing it.

Know the UUID format your test expects

A UUID contains 128 bits. Its usual text form has 32 hexadecimal digits separated into groups of 8, 4, 4, 4 and 12. For version 4, the third group starts with 4; the fourth starts with 8, 9, a or b. The version and variant reserve six bits, leaving 122 for random data. These details come from RFC 9562.

For this fixture, use lowercase letters, keep the hyphens and omit braces. Match the representation accepted by your application rather than changing formats midway through the test.

Generate three values and assign them once

1. Open the UUID Generator and select Version 4 (random).
2. Set the quantity to 3 and choose JSON array.
3. Leave Uppercase, Remove hyphens and Wrap in braces unchecked.
4. Press Generate UUIDs, then Copy all.
5. Assign the first value to the project and the next two to its tasks. Save that mapping with your fixture.

The tool supports batches of 1 to 500 and also offers a plain list. Its generation code uses crypto.getRandomValues() in the browser and sets the version and variant bits. It does not create your database rows or establish relationships between them.

Build a JSON fixture with a shared parent ID

The following values are illustrative test identifiers. Replace them with your generated values while preserving the same parent reference in both tasks:

{
  "project": {
    "id": "93762841-a996-4680-8ec8-26757532f0bf",
    "name": "Demo newsletter"
  },
  "tasks": [
    {
      "id": "45d788f3-aba9-4f24-85d7-ec501eb2946d",
      "project_id": "93762841-a996-4680-8ec8-26757532f0bf",
      "title": "Draft subject line"
    },
    {
      "id": "9073a5b3-68b6-4036-bc38-9698bf8ffb33",
      "project_id": "93762841-a996-4680-8ec8-26757532f0bf",
      "title": "Review preview text"
    }
  ]
}

The project ID appears three times intentionally. It identifies one project, then links two tasks to that project. Only the three record IDs need to be distinct; replacing every repeated UUID would break the fixture.

Check the document with the JSON Formatter and Validator. For broken punctuation, use the guide to common JSON errors. Valid JSON alone does not confirm that parent references exist or that your importer accepts the field names.

Check identifiers separately from JSON syntax

After parsing the saved file into a variable named fixture, this small JavaScript check tests the chosen text format, duplicate record IDs and the expected parent relationship:

const ids = [fixture.project.id, ...fixture.tasks.map(task => task.id)];
const v4 = /^[0-9a-f]{8}-[0-9a-f]{4}-4[0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$/;

if (!ids.every(id => v4.test(id)) || new Set(ids).size !== ids.length) {
  throw new Error("Check record IDs");
}
if (!fixture.tasks.every(task => task.project_id === fixture.project.id)) {
  throw new Error("Check project references");
}

MDN documents JSON.parse() for turning JSON text into a JavaScript value; invalid JSON throws a syntax error. The regular expression checks appearance, not randomness or authenticity.

Import the same mapping into a test database

For existing test tables with compatible ID columns, the equivalent seed statements use the same mapping. Adjust the table and column names to your schema:

INSERT INTO projects (id, name) VALUES
('93762841-a996-4680-8ec8-26757532f0bf', 'Demo newsletter');

INSERT INTO tasks (id, project_id, title) VALUES
('45d788f3-aba9-4f24-85d7-ec501eb2946d',
 '93762841-a996-4680-8ec8-26757532f0bf', 'Draft subject line'),
('9073a5b3-68b6-4036-bc38-9698bf8ffb33',
 '93762841-a996-4680-8ec8-26757532f0bf', 'Review preview text');

Insert the parent before its children. Retain primary-key or unique constraints, and foreign-key constraints where your schema supports them. Use an isolated test database and its documented reset procedure before replaying a seed file; inserting the same IDs into an existing fixture can cause a duplicate-key failure.

Save fixed fixtures in version control. Generate new IDs when testing creation behavior, but reuse saved IDs when a test depends on a known record. The text comparison workflow can help review an edited seed file and spot an accidentally changed parent reference.

Avoid treating an identifier as a guarantee

Random UUID collisions are possible, so keep application uniqueness checks. The all-zero nil UUID is a special value, not a random v4 record ID. Use it only when a test specifically needs that value. RFC 9562 also warns against granting access merely because someone possesses a UUID.

If you generate values in browser code instead, MDN describes crypto.randomUUID() as a v4 generator using secure randomness, available in supporting secure contexts such as HTTPS. This API is a separate programming option; the on-site tool uses getRandomValues().

Keep authentication and permission checks in your application. For this fixture, success means three distinct record IDs, two correct parent references and a saved file that your test can replay consistently.