Sometimes you don't need another test-data library. You just need 1,000 unique identifiers to populate a database, test an API, or build a realistic mock dataset.
Generating them is easy. Making sure they're suitable for your tests takes a little more thought.
Here are four things worth checking.
- Choose the right UUID version
UUID v4 and UUID v7 are both 128-bit identifiers, but they have different characteristics.
UUID v4 is random-based.
It's a straightforward choice when you need independent identifiers without encoding creation time.
UUID v7 includes a Unix timestamp in milliseconds, followed by additional bits.
This makes v7 identifiers naturally group by generation time, which may improve index locality in certain database workloads.
However, v7 doesn't guarantee exact generation order for identifiers created within the same millisecond unless the generator implements additional monotonic behavior.
For disposable test data, either version can work. Choose based on what your application actually expects.
- Check for duplicates
Even if your UUID generator is designed to produce unique values, verifying the output is useful when preparing a test fixture.
In JavaScript, you can check a generated list like this:
const ids = [
// Paste your generated UUID strings here
];
const uniqueCount = new Set(
ids.map(id => id.toLowerCase())
).size;
console.log({
total: ids.length,
unique: uniqueCount,
duplicates: ids.length - uniqueCount
});
A proper test fixture should contain the number of unique identifiers you expected.
- Validate the UUID format
A string containing hexadecimal characters isn't automatically a valid UUID.
For a simple format check supporting UUID v4 and v7:
const uuidPattern =
/^[0-9a-f]{8}-[0-9a-f]{4}-[47][0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$/i;
const invalidIds = ids.filter(
id => !uuidPattern.test(id)
);
console.log("Invalid IDs:", invalidIds);
This checks the canonical structure, version, and variant bits. It doesn't prove that an identifier was generated securely.
- Don't confuse UUIDs with security tokens
UUIDs are identifiers, not a replacement for authorization.
Even if an identifier is difficult to guess, your application still needs proper access controls.
UUID v7 also reveals an approximate creation timestamp, which can matter if creation time is sensitive.
For password reset tokens or API secrets, use a security-specific token-generation approach instead of treating ordinary database IDs as secrets.
Generating test IDs quickly
For UUID v4, modern JavaScript environments provide:
const ids = Array.from(
{ length: 1000 },
() => crypto.randomUUID()
);
If you specifically need UUID v7, use a generator that implements RFC 9562.
I built a small browser-based tool that supports UUID v4, UUID v7, bulk generation, and validation without requiring a signup:
https://devrivettools.com/uuid-generator
It's useful when you want to prepare sample IDs without setting up a separate script.
What do you normally use for database IDs: integers, UUID v4, or UUID v7?
Top comments (0)