DEV Community: Genory Team

Synthetic Data vs Fake Data: What's the Difference and When Should You Use Each?

Genory Team — Sun, 18 Oct 2026 05:00:00 +0000

Developers often use the terms fake data, dummy data, mock data, and synthetic data as if they all mean the same thing.

Sometimes that is harmless.

Sometimes it causes real confusion.

Consider these two records:

{
  "name": "Test User",
  "email": "test@test.com",
  "city": "Test City"
}

and:

{
  "name": "Anna Schneider",
  "email": "anna.schneider@example.com",
  "city": "Hamburg",
  "country": "DE",
  "postalCode": "20095"
}

Both are not real customer records.

But they serve very different purposes.

The first is obviously placeholder data.

The second is designed to resemble the structure and relationships found in real data.

That difference becomes important when you're testing applications, APIs, imports, forms, analytics pipelines, or databases.

So what exactly is synthetic data, and how is it different from ordinary fake data?

What is fake data?

Fake data is any information created specifically for testing, demonstrations, development, or other non-production purposes.

It can be extremely simple:

John Doe
123 Fake Street
test@example.com

Or even:

foo
bar
123

The goal is usually not realism.

The goal is simply to have something to put into a field.

For example, if you're testing whether a form submits correctly, this might be enough:

{
  "firstName": "Test",
  "lastName": "User",
  "email": "test@example.com"
}

Nothing about that record needs to resemble a real user.

It only needs to satisfy the basic input requirements.

What is synthetic data?

Synthetic data goes a step further.

It is generated data designed to imitate the properties, structure, distributions, or relationships of real data without copying actual records.

For a simple customer profile, that could mean:

{
  "firstName": "Anna",
  "lastName": "Schneider",
  "email": "anna.schneider@example.com",
  "country": "DE",
  "city": "Hamburg",
  "postalCode": "20095"
}

The person is not meant to represent a real customer.

But the record is internally plausible.

The fields relate to each other in a meaningful way.

That makes synthetic data useful for testing systems that behave differently depending on realistic combinations of values.

Fake data can be intentionally unrealistic

Sometimes unrealistic data is exactly what you want.

Suppose you're testing whether a username field accepts a value.

This may be perfectly fine:

test123

You do not need a sophisticated identity generator.

Likewise, if you're testing a calculator:

2 + 2 = 4

there is no benefit in generating realistic financial records.

Simple fake data is often best for:

unit tests
simple form tests
exact business rules
predictable fixtures
small examples
documentation

The simpler the test, the simpler the data should usually be.

Synthetic data is useful when relationships matter

Now imagine a checkout system.

You may need:

name
country
city
postal code
phone number
currency
tax rules
shipping options

If every field is generated independently, you might get:

{
  "country": "DE",
  "city": "Tokyo",
  "postalCode": "SW1A 1AA",
  "phone": "+1 212 555 0100"
}

Every individual value looks valid.

Together they make little sense.

If your application uses those relationships, your tests become less useful.

Synthetic data can preserve context.

For example:

{
  "country": "DE",
  "city": "Hamburg",
  "postalCode": "20095",
  "phone": "+49 40 12345678"
}

That is much more useful for testing country-aware behavior.

Dummy data is usually simpler

The term dummy data usually refers to placeholder information.

Examples:

John Doe
Company ABC
123456
example@example.com

It is often used for:

screenshots
demos
temporary UI development
prototypes
documentation

Dummy data does not necessarily try to reproduce real-world distributions or relationships.

It just fills space.

That makes it useful.

But it is not automatically realistic.

Mock data is slightly different

Mock data often appears in the context of mocked systems.

For example, a frontend may call an API that does not exist yet.

Instead of making a real request:

const response = await fetch("/api/users");

the frontend might receive a mocked response:

{
  "id": 42,
  "name": "Anna",
  "plan": "pro"
}

The important concept is not whether the values are realistic.

The important concept is that the response stands in for another system.

Mocking is about replacing dependencies.

Synthetic data is about generating realistic data.

They can absolutely be used together.

A mocked API can return synthetic data.

Test fixtures are about repeatability

A fixture is data prepared for a test.

For example:

const user = {
  id: "user-42",
  plan: "pro",
  balance: 100
};

Fixtures are often deliberately static.

That is useful because the expected state is obvious.

If a test fails, you know exactly what the input was.

Synthetic data can also be used as a fixture, especially when it is seeded.

For example:

seed = checkout-user-42

The generator can recreate the same synthetic customer every time.

That combines realism with reproducibility.

Realism should match the test

One mistake developers make is assuming that more realistic data is always better.

It isn't.

Suppose you're testing this function:

function addTax(price, rate) {
  return price + price * rate;
}

You probably want a test like:

expect(addTax(100, 0.19)).toBe(119);

Generating a realistic customer, address, order, product catalog, and payment method adds nothing.

But if you're testing a full checkout flow, realistic synthetic data becomes much more useful.

A simple rule:

Use the least complicated data that still tests the behavior you care about.

Production data is not test data

There is another category developers sometimes use:

copied production data.

For example:

export 1,000 customers
import into staging

This may create realistic test conditions.

It also creates privacy and security risks.

Production data can contain:

names
emails
addresses
phone numbers
account identifiers
transaction histories
internal notes
sensitive metadata

Once copied into development, that information may appear in:

local databases
logs
screenshots
test exports
bug reports
backups
developer laptops

Synthetic data avoids this problem by generating new records rather than copying actual customers.

Synthetic does not automatically mean anonymous

This distinction is important.

If you take real customer data and simply replace:

John Smith

with:

User 123

the dataset is not necessarily synthetic.

Other attributes may still allow the person to be identified.

For example:

location
age
transaction history
rare job title
specific timestamp

can potentially reveal identity when combined.

Truly synthetic data should be generated rather than merely renaming real individuals.

Format-valid data is another category

Sometimes realism means following a technical format.

For example:

UUID
IBAN
MAC address
IMEI
IP address
phone number
email

A useful test value may need to satisfy structural rules.

For example, this:

DE123

is not very useful for testing a real IBAN validator.

You may instead need an identifier that follows:

country length
BBAN structure
checksum rules

That makes the test data technically realistic.

But an important distinction remains:

Format-valid does not mean real-world verified.

A generated IBAN can satisfy structural checks without representing an existing bank account.

A generated device identifier can match the expected format without representing an actual device.

Synthetic data can preserve distributions

For some applications, individual realistic records are not enough.

Imagine testing analytics.

Production data might contain:

70% free users
20% standard users
10% premium users

A naive generator could produce:

33% free
33% standard
33% premium

That may create misleading results.

A more advanced synthetic dataset could preserve the intended distribution:

free: 70%
standard: 20%
premium: 10%

Likewise, synthetic datasets can model relationships such as:

country → currency
country → phone format
product → price range
subscription → feature usage
age group → behavior

This becomes useful for:

analytics
machine learning testing
load testing
dashboards
data pipelines
BI systems

Synthetic data can still contain edge cases

Realistic does not mean normal.

Good test datasets should include unusual scenarios.

For example:

very long names
empty optional values
Unicode characters
leap-day dates
zero-value orders
duplicate records
minimum values
maximum values
unusual postal formats

These cases often expose more bugs than ordinary records.

A good synthetic-data system should allow realism and deliberate edge cases to coexist.

Example: signup testing

For a simple unit test, this may be enough:

{
  "email": "test@example.com"
}

For integration testing:

{
  "firstName": "Anna",
  "lastName": "Schneider",
  "email": "anna.schneider@example.com",
  "country": "DE"
}

For edge-case testing:

{
  "firstName": "A".repeat(100),
  "lastName": "Schneider",
  "email": "anna+very-long-alias@example.com",
  "country": "DE"
}

Different tests deserve different data strategies.

Example: API testing

Imagine this endpoint:

POST /customers

The API expects:

{
  "name": "string",
  "email": "string",
  "country": "string",
  "phone": "string"
}

A basic fixture could be:

{
  "name": "Test",
  "email": "test@example.com",
  "country": "DE",
  "phone": "123"
}

That may be enough to test JSON parsing.

But it is not very useful for testing phone validation.

A realistic synthetic fixture could be:

{
  "name": "Anna Schneider",
  "email": "anna.schneider@example.com",
  "country": "DE",
  "phone": "+49 40 12345678"
}

Now the same payload exercises more realistic application behavior.

Example: database testing

Suppose you need 100,000 customer rows.

Writing static fixtures is obviously impractical.

A synthetic generator can create:

100,000 records
multiple countries
different subscription plans
varied signup dates
different order histories

That is useful for:

query testing
pagination
indexing
search
analytics
performance testing

For this kind of workload, synthetic data becomes much more valuable than simple dummy records.

Seeds make synthetic data reproducible

Pure generation introduces a problem:

run 1 → dataset A
run 2 → dataset B
run 3 → dataset C

If dataset A exposes a bug, you may want it again.

That is where seeds help.

For example:

seed = regression-42

can produce the same synthetic dataset repeatedly.

Then a CI failure can report:

Generator: customer
Seed: regression-42

A developer can recreate the exact input locally.

This makes synthetic data much more practical for automated testing.

Don't use synthetic data everywhere

Synthetic data is not the answer to every problem.

Use static fixtures when:

exact values matter
the test is small
readability is important
business rules are simple

Use synthetic data when:

realistic variation matters
you need many records
relationships between fields matter
you want multiple locales
you need performance datasets
production data should not be copied

Use deliberately invalid data when:

testing validators
testing error messages
testing edge cases
testing defensive code

The best test suite usually combines all three.

A practical hierarchy

I like to think about test data in layers.

Level 1: Placeholder data

foo
bar
123

Useful for very simple tests.

Level 2: Static fixtures

{
  "email": "test@example.com",
  "plan": "pro"
}

Useful for predictable business logic.

Level 3: Synthetic records

{
  "name": "Anna Schneider",
  "email": "anna.schneider@example.com",
  "country": "DE",
  "city": "Hamburg"
}

Useful for realistic application testing.

Level 4: Synthetic datasets

10,000 related records
multiple countries
weighted distributions
edge cases

Useful for analytics, system testing, and performance testing.

The higher the level, the more complexity you introduce.

Only move up when the test actually benefits from it.

Where tools like Genory fit

Developer tools such as Genory focus on generating synthetic test data and structured developer fixtures without requiring real customer records.

For example, you can work with:

synthetic profiles
custom datasets
addresses
UUIDs
format-based test identifiers
validators
developer utilities

For more complex fixture generation, you can start with the Genory test-data tools.

For programmatic workflows, the current API documentation is available at genory.dev/docs.

The goal is not to replace explicit test fixtures.

The goal is to make realistic test data easier to create when realism actually helps.

A simple rule

When choosing test data, ask:

Does this test care about the exact value?

If yes:

Use an explicit fixture.

If no, ask:

Does realism matter?

If no:

Use simple fake data.

If yes:

Use synthetic data.

And if the test must be reproducible:

Use a seed.

Final thought

Fake data and synthetic data are not enemies.

They solve different problems.

Fake data is often simple, obvious, and predictable.

Synthetic data is useful when your tests benefit from realistic structure, relationships, variation, or scale.

The mistake is not choosing one over the other.

The mistake is using complicated data where simple fixtures would work — or using meaningless placeholders when your application depends on realistic relationships.

Choose the data based on the behavior you're trying to test.

Not based on which generator looks more impressive.

10 Small Developer Tools That Save Time During Testing

Genory Team — Thu, 15 Oct 2026 09:00:00 +0000

Testing usually isn't slowed down by one huge problem.

It is slowed down by dozens of tiny interruptions.

You need a UUID.

Then a realistic test profile.

Then a valid-looking IBAN for a form test.

Then a random MAC address.

Then you need to compare two values, generate another dataset, or check whether an identifier has the right structure.

None of these tasks is difficult.

But every context switch costs time.

Here are 10 small developer tools and workflows that can make everyday testing faster.

1. UUID Generator

UUIDs are one of the most common identifiers used in modern applications.

You may need them for:

database records
API resources
test fixtures
message IDs
temporary objects
distributed systems

Instead of manually inventing IDs like:

test-user-123

you can generate proper UUIDs.

For example:

550e8400-e29b-41d4-a716-446655440000

For many projects, UUID v4 is still the simplest choice.

For newer systems where time grouping is useful, UUID v7 can also be interesting.

A good UUID tool should make it easy to generate:

UUID v4
UUID v7
multiple UUIDs at once

without opening a terminal or writing a helper script.

2. Synthetic Profile Generator

Sometimes you need more than a single random value.

You need a complete test profile:

{
  "firstName": "Anna",
  "lastName": "Schneider",
  "email": "anna.schneider@example.com",
  "country": "DE",
  "city": "Hamburg"
}

This is useful for:

signup flows
CRM testing
account creation
admin dashboards
imports
UI screenshots
API payloads

The important part is that the data is synthetic.

You should not have to copy real customer records into development just to make a form look realistic.

3. Custom Test Data Generator

Predefined profiles are convenient, but sometimes you need your own schema.

For example:

customer_name
email
order_total
status
created_at

A custom generator lets you define fields instead of accepting a huge generic profile.

Conceptually:

[
  { "name": "customer_name", "type": "fullName" },
  { "name": "email", "type": "email" },
  { "name": "order_total", "type": "decimal" },
  { "name": "status", "type": "choice" }
]

That gives you exactly the dataset your test needs.

Not 30 unrelated fields.

4. Address Generator

Address forms are surprisingly annoying to test.

A typical address includes several related values:

street
house number
city
postal code
region
country

Randomly generating each field independently can create unrealistic combinations.

For UI and validation testing, it is often more useful to generate addresses that at least resemble the expected structure for a country.

This helps when testing:

checkout forms
delivery forms
CRM systems
location fields
imports
validation rules

The goal is not to generate a real resident.

The goal is to produce realistic-looking test input.

5. IBAN Validator

Banking forms are another place where random strings are not very useful.

An IBAN validator can check things like:

country format
length
BBAN structure
MOD-97 checksum

That makes it easy to build targeted test cases.

For example:

valid structure
wrong checksum
wrong length
unsupported country
illegal character

One important distinction:

A format-valid IBAN is not proof that a real bank account exists.

That matters both in your code and in the wording of your UI.

6. Password Generator

Developers often need passwords for:

test accounts
local environments
demos
seeded users
staging systems

Typing:

password123

into every test account is convenient but unrealistic.

A password generator lets you test things like:

minimum length
uppercase requirements
special characters
numbers
very long passwords

For actual secrets, use a proper cryptographically secure generator.

For UI testing, generated passwords are also useful for checking how forms behave with different lengths and character sets.

7. MAC Address Generator

If you work with:

networking tools
device management
inventory systems
IoT software
hardware dashboards

you may need MAC-address fixtures.

For example:

00:1A:2B:3C:4D:5E

A dedicated generator is faster than manually editing old values.

It also helps avoid accidentally reusing production device identifiers in demos or screenshots.

8. IMEI Test Data

Mobile-device systems sometimes require IMEI-shaped values.

That can happen in:

device registration
telecom dashboards
inventory systems
mobile-device management
validation forms

Again, the useful distinction is:

format-valid test data

versus:

verified real-world device

Those are not the same thing.

A generator can help you test formatting and validation logic without using real device identifiers.

9. Reproducible Seeded Data

Random data is great until a test fails.

Suppose your CI pipeline generates a customer profile and triggers a bug.

You run the test again.

Different data.

The bug disappears.

This is why seeded generation is useful.

Instead of:

random data every time

you can use:

seed = checkout-42

If the generator is deterministic, the same seed produces the same fixture.

That makes bug reports much more useful:

Test failed
Generator: customer-profile
Seed: checkout-42

Now another developer can reproduce the exact same dataset.

10. API-Based Generation

Manual tools are perfect when you're exploring.

Automation becomes useful when you repeat the same workflow.

Instead of opening a browser every time, your test setup can request synthetic data programmatically.

Conceptually:

curl --request POST "https://genory.dev/api/profile" \
  --header "Authorization: Bearer $GENORY_API_KEY" \
  --header "Content-Type: application/json" \
  --data '{
    "country": "DE",
    "amount": 1,
    "fields": ["firstName", "lastName", "email"]
  }'

Now the fixture can be created from:

test scripts
CI pipelines
local development tools
seed scripts
API tests

That removes repetitive manual work.

The real value is reducing context switching

None of these tools is revolutionary by itself.

That is exactly the point.

Developer productivity is often improved by removing small interruptions.

Consider this workflow:

Need UUID
↓
Search for generator
↓
Need address
↓
Search again
↓
Need IBAN validation
↓
Open another site
↓
Need synthetic profile
↓
Write temporary script

Every step is small.

Together they create friction.

A single toolbox can reduce that to:

open tools
↓
generate
↓
copy
↓
continue working

That is where small utilities become valuable.

Keep test data separate from production data

There is also a security and privacy benefit.

Development environments often have weaker controls than production.

Test data can end up in:

screenshots
logs
local databases
bug reports
developer laptops
staging environments
temporary exports

Synthetic data reduces the temptation to copy real customer information into those places.

It does not solve every security problem.

But it removes one unnecessary source of risk.

Use the right tool for the job

A useful rule is:

Need exact business-rule test?
→ Write an explicit fixture.

Need realistic variation?
→ Use synthetic data.

Need reproducibility?
→ Add a seed.

Need automation?
→ Use an API.

Need production verification?
→ Use the appropriate real verification service.

No generator should replace actual business validation when real-world verification is required.

One toolbox instead of ten tabs

This is also the idea behind Genory.

It combines developer utilities, synthetic test-data generators and validators in one place.

For example, you can work with:

synthetic profiles
custom datasets
UUIDs
addresses
IBAN validation
device-format test data
other development utilities

For UUID testing specifically, there is a dedicated UUID Generator.

For banking-format tests, you can use the IBAN Validator.

And for programmatic workflows, the current API documentation is available at genory.dev/docs.

Final thought

The best developer tools are not always the biggest ones.

Sometimes the most useful tool is the one that saves you 30 seconds.

Because saving 30 seconds once is irrelevant.

Saving 30 seconds fifty times a week is a workflow improvement.

Remove the tiny interruptions.

Keep your test data synthetic.

Automate what becomes repetitive.

And spend more time testing your application than preparing data for the test.

How to Build Reproducible Test Fixtures with Seeded Synthetic Data

Genory Team — Tue, 13 Oct 2026 09:00:00 +0000

Random test data is useful.

Until a test fails.

Then randomness can become your enemy.

Imagine a CI job fails with a generated dataset containing a specific combination of:

name
country
date
order value
status
identifier

You run the test again.

It passes.

Run it a third time.

It passes again.

The failure is gone because the generator created different data.

This is exactly where seeded synthetic data becomes useful.

A seed lets you keep the benefits of generated test data while making the output reproducible.

What does a seed actually do?

A deterministic generator starts with an initial value:

seed = 42

The generator uses that value as the starting state for producing pseudo-random values.

If the algorithm and configuration remain the same:

seed = 42

should produce the same sequence again.

Conceptually:

seed 42
  ↓
Anna
Hamburg
20095
€184.22
active

Run it again with the same seed:

seed 42
  ↓
Anna
Hamburg
20095
€184.22
active

Change the seed:

seed 43

and you get a different dataset.

That makes the seed a compact way to describe an entire generated fixture.

Why this matters in CI

Consider a test like this:

test("checkout accepts generated customer data", async () => {
  const customer = generateCustomer();

  const result = await checkout(customer);

  expect(result.success).toBe(true);
});

If generateCustomer() returns different values every time, a failure can be difficult to reproduce.

Instead, imagine:

const customer = generateCustomer({
  seed: "checkout-1842"
});

Now your CI output can report:

Test failed.
Seed: checkout-1842

A developer can run the test locally using exactly the same seed.

That turns:

"It failed once in CI."

into:

"Run this exact dataset."

That is a huge debugging improvement.

Randomness is not the same as unpredictability

Developers sometimes assume that test data should always be completely unpredictable.

Usually it should not.

Production systems may need cryptographically secure randomness.

Test fixtures usually need something else:

controlled variation.

You want datasets that differ enough to expose assumptions while still being reproducible when something breaks.

For testing, deterministic pseudo-randomness is often more useful than true randomness.

A simple seeded generator

Here is a deliberately small example:

function createRng(seed) {
  let state = seed >>> 0;

  return function () {
    state = (state * 1664525 + 1013904223) >>> 0;
    return state / 4294967296;
  };
}

Now:

const random = createRng(12345);

console.log(random());
console.log(random());
console.log(random());

Calling the same function again with:

createRng(12345)

produces the same sequence.

For real applications, you would normally use a mature deterministic PRNG library rather than inventing one.

The important idea is the deterministic relationship:

same seed + same algorithm = same sequence

Build fixtures from the seeded source

Once you have a seeded random source, other values should derive from it.

For example:

function pick(random, values) {
  const index = Math.floor(random() * values.length);
  return values[index];
}

Then:

const random = createRng(42);

const country = pick(random, ["DE", "FR", "NL"]);
const status = pick(random, ["active", "pending", "blocked"]);

If you recreate the generator with seed 42, you should receive the same choices.

That is the foundation of reproducible synthetic data.

The whole pipeline must be deterministic

A common mistake is seeding only one part of the generator.

For example:

const random = seededRandom(seed);

const name = generatedFromSeed(random);
const email = generatedFromSeed(random);

const createdAt = new Date();

The name and email are reproducible.

The timestamp is not.

If reproducibility matters, avoid hidden dynamic inputs such as:

current time
machine hostname
process ID
random UUID
timezone
environment-specific ordering

Instead, make them explicit inputs.

For example:

generateFixture({
  seed: 42,
  now: "2026-10-05T12:00:00Z"
});

Now both randomness and time are controlled.

Version your fixture generators

There is another subtle problem.

Imagine this configuration:

seed = 42

generates:

{
  "name": "Anna Schneider",
  "country": "DE"
}

Then six months later you improve your generator.

You add more names and change the country selection algorithm.

Now seed 42 might produce:

{
  "name": "Jonas Weber",
  "country": "NL"
}

Technically, the seed stayed the same.

But the generator changed.

If you rely heavily on reproducibility, save the generator version too:

generatorVersion = 3
seed = 42

A failure report can then contain:

Fixture generator: v3
Seed: 42

That is much more reliable than storing only the seed.

Seeds should describe scenarios

You do not have to use numbers.

Readable seeds can make test output easier to understand.

For example:

checkout-basic
checkout-eu-user
checkout-large-order
import-invalid-address
profile-long-name

Internally, the string can be hashed into a numeric seed.

This gives your tests meaningful names while preserving deterministic generation.

Instead of:

generateUser(91281);

you can write:

generateUser("signup-german-user");

The second version communicates intent.

Don't make every test depend on huge generated profiles

Synthetic-data systems can generate enormous records.

That does not mean every test should use them.

Suppose you are testing:

email normalization

You probably need:

{
  "email": "Test.User@Example.com"
}

You probably do not need:

{
  "name": "...",
  "address": "...",
  "phone": "...",
  "company": "...",
  "job": "...",
  "iban": "...",
  "device": "...",
  "orderHistory": []
}

Large fixtures increase cognitive load.

Generate only what the test actually needs.

A useful principle is:

Small deterministic fixtures for unit tests, richer synthetic datasets for integration and system tests.

Separate normal fixtures from edge cases

Pure randomness is surprisingly bad at finding many important bugs.

A generator may happily produce normal data thousands of times without ever creating:

an empty string
a 255-character name
February 29
a negative value
a duplicate identifier
a zero-value order
a Unicode-heavy address

So combine generated fixtures with deliberate edge cases.

For example:

const cases = [
  generateCustomer("normal-customer"),
  generateCustomer("another-customer"),
  {
    ...generateCustomer("long-name"),
    name: "A".repeat(255)
  }
];

Randomness should complement scenario design, not replace it.

Keep relationships between fields deterministic

Realistic fixtures often contain dependent fields.

For example:

country = DE
city = Hamburg
postalCode = 20095
phonePrefix = +49

A poor generator might independently produce:

country = DE
city = Toronto
postalCode = SW1A 1AA
phonePrefix = +81

That may be useful for some validation tests.

But it is not a realistic German profile.

If your application depends on relationships between fields, derive those values from the same deterministic context.

Conceptually:

const country = generateCountry(random);

const address = generateAddress({
  random,
  country
});

const phone = generatePhone({
  random,
  country
});

Now the fixture stays coherent while remaining reproducible.

Save the seed when reporting errors

If generated data is used in automated tests, always include the seed in failure output.

For example:

try {
  await runCheckoutTest(fixture);
} catch (error) {
  console.error(`Fixture seed: ${seed}`);
  throw error;
}

Your CI logs might then show:

FAIL checkout.integration.test.js

Expected: 200
Received: 500

Fixture seed: checkout-regression-9381

That one line may save an hour of debugging.

Seeds are also useful outside automated tests

Reproducible datasets help with more than CI.

Bug reports

Instead of attaching a huge JSON file:

Use seed: bug-2841

UI development

Designers and frontend developers can repeatedly work with the same profile dataset.

Database demos

Seeded data keeps screenshots and demonstrations consistent.

Performance testing

Specific seeds can represent different dataset shapes.

For example:

small-shop
enterprise-customer
high-order-volume

QA

A tester can send a developer:

Generator: profile
Seed: qa-login-114

Both sides can reproduce the same data.

But don't mistake seeds for security

A deterministic seed is not a secret.

If someone knows:

seed = customer-demo

and knows the generator algorithm, they may be able to reproduce the same data.

That is completely fine for synthetic test fixtures.

It is not fine for generating:

passwords
encryption keys
API tokens
password-reset tokens
session secrets

Security-sensitive values require cryptographically secure generation.

Seeded fixture generation and secure random generation solve different problems.

A practical test-data strategy

A good setup might contain three layers.

Layer 1: Explicit fixtures

For exact business rules:

{
  "price": 100,
  "discount": 10
}

Layer 2: Seeded synthetic fixtures

For realistic variation:

seed = checkout-customer-42

Layer 3: Randomized exploratory tests

For discovering unexpected combinations:

random seed generated per run

The trick is to log the random seed.

If an exploratory run fails:

Random seed: 9182811

you can convert an unpredictable failure into a reproducible one.

Generate random seeds — but record them

This gives you a useful hybrid approach.

At test startup:

const seed =
  process.env.TEST_SEED ??
  Math.floor(Math.random() * 1_000_000);

Then print it:

console.log(`TEST_SEED=${seed}`);

Your CI run might use:

TEST_SEED=718421

If the test fails, reproduce it locally:

TEST_SEED=718421 npm test

Now each CI execution explores new data while every failure remains reproducible.

That is often the best of both worlds.

Using Genory for reproducible datasets

You can experiment with synthetic test data using the Genory Test Data tools.

For dataset-style workflows, Genory can help generate structured test records while keeping development data separate from real customer information.

For programmatic workflows and supported endpoints, the current API documentation is available at:

genory.dev/docs

Whether you use Genory, a local fixture library, or your own generator, the underlying principle remains the same:

configuration
+
seed
+
generator version
=
reproducible fixture

A useful failure report

Instead of logging an entire fixture, you may be able to log:

Generator: customer-profile
Version: 3
Seed: checkout-regression-9381
Locale: de-DE
Now: 2026-10-05T12:00:00Z

That is enough information to reconstruct the dataset.

It is compact, searchable and easy to paste into a bug report.

Final thought

Generated test data should not make bugs harder to reproduce.

It should make bugs easier to discover.

The key is controlling randomness instead of eliminating it.

Use synthetic data to introduce variation.

Use seeds to make that variation repeatable.

And whenever a randomized test fails, save the seed.

Because:

A random failure you cannot reproduce is frustrating.

A random failure with a seed is a test case.

How IBAN Validation Actually Works (and What It Does Not Prove)

Genory Team — Sat, 10 Oct 2026 09:00:00 +0000

An IBAN validator often looks deceptively simple.

A user enters something like:

DE89 3704 0044 0532 0130 00

The application shows a green checkmark.

Done, right?

Not quite.

A valid-looking IBAN can pass several mathematical and structural checks without proving that the bank account actually exists, belongs to a particular person, or can receive a payment.

For developers, that distinction matters.

Let's look at what IBAN validation really does.

What is inside an IBAN?

An IBAN — International Bank Account Number — is a structured identifier.

At a high level, it contains:

COUNTRY + CHECK DIGITS + BBAN

For example:

DE89 3704 0044 0532 0130 00

can be viewed conceptually as:

DE | 89 | 370400440532013000

The first two characters are the country code.

The next two digits are check digits.

The remaining part is the BBAN — the country-specific Basic Bank Account Number.

The important detail is that the BBAN structure differs by country.

Germany does not use the same internal structure as the Netherlands or the United Kingdom.

So an IBAN validator should do more than simply check:

starts with two letters

Step 1: Normalize the input

Users rarely type an IBAN in exactly one format.

You may receive:

DE89 3704 0044 0532 0130 00

or:

de89370400440532013000

or:

DE89370400440532013000

A validator usually starts by normalizing the value.

Conceptually:

const normalized = iban
  .replace(/\s+/g, "")
  .toUpperCase();

After normalization:

DE89370400440532013000

This normalized value is much easier to validate and store consistently.

A useful rule is:

Store the normalized identifier and add spaces only for display.

Also remember that an IBAN is text.

Do not treat it as a number.

Leading zeros may be meaningful.

Step 2: Check the country code

The first two characters identify the IBAN country or territory format.

For example:

DE → Germany
NL → Netherlands
GB → United Kingdom

A validator should confirm that the prefix represents a supported IBAN format.

If you receive:

ZZ123456789

and ZZ is not part of your supported format table, you should reject it before doing deeper checks.

This also determines which country-specific length and BBAN rules should be applied.

Step 3: Check the expected length

IBANs do not all have the same length.

The required length depends on the country.

That means this is not enough:

if (iban.length >= 15 && iban.length <= 34) {
  // valid?
}

A proper validator should ask:

What is the expected length for this country?

Then compare the normalized input against that exact value.

For example, if a specific country's IBAN format requires 22 characters, then:

21 characters → invalid
22 characters → continue validation
23 characters → invalid

Length validation catches many common input errors immediately:

missing characters
accidental extra digits
truncated copy/paste
wrong country format

But length alone obviously does not prove that the IBAN is correct.

Step 4: Validate the BBAN structure

The part after the first four characters is the country-specific BBAN.

This is where country formats become more interesting.

One country may expect:

bank code + account number

Another might include:

bank code + branch code + account number

Some formats contain only digits.

Others allow letters.

For developers, this means a validator may need country-specific patterns.

Conceptually:

const rules = {
  DE: {
    length: 22,
    bbanPattern: /^[0-9]{18}$/
  },
  // additional country definitions...
};

Real implementations need a complete and maintained rule source rather than a tiny hardcoded example like this.

The important principle is:

Validate according to the selected country's structure, not one universal regular expression.

Step 5: The MOD-97 checksum

This is the part most people associate with IBAN validation.

IBANs use a checksum based on modulo 97.

The algorithm is elegant.

Start with a normalized IBAN:

DE89370400440532013000

Move the first four characters to the end:

370400440532013000DE89

Then convert letters to numbers.

The mapping is:

A = 10
B = 11
C = 12
...
Z = 35

So:

D = 13
E = 14

The rearranged value becomes a very large numeric string.

Then calculate:

number mod 97

A valid IBAN produces:

remainder = 1

Conceptually:

if (mod97(convertedValue) === 1) {
  // checksum passes
}

Don't parse the entire value as one JavaScript number

This is an important implementation detail.

The converted numeric string can be much larger than JavaScript's safe integer range.

So this is a bad idea:

const value = Number(hugeIbanNumber);
const remainder = value % 97;

You can lose precision.

Instead, calculate the modulo incrementally.

For example:

function mod97(numberString) {
  let remainder = 0;

  for (const digit of numberString) {
    remainder = (remainder * 10 + Number(digit)) % 97;
  }

  return remainder;
}

This never requires representing the entire giant number at once.

The same concept works in almost any programming language.

What does a passing checksum actually prove?

This is the most important part of the article.

A passing MOD-97 check proves something very specific:

The characters are mathematically consistent with the IBAN checksum.

That is useful.

It can detect many:

mistyped digits
transcription errors
malformed values
accidental character changes

But it does not prove that:

the account exists
the account is open
the account belongs to the person entering it
the bank details are currently active
the account can receive a particular payment
the account has a balance
the payment will succeed

That difference should also appear in your user interface.

Instead of displaying:

Bank account verified ✓

a format validator should say something more precise:

IBAN format and checksum valid ✓

Those are very different claims.

Format validation vs account verification

A good mental model is to separate validation into layers.

Layer 1: Syntax

Questions such as:

Does it contain allowed characters?

Layer 2: Country and length

Questions such as:

Does the country exist in the supported IBAN format list?
Does this value have the expected number of characters?

Layer 3: BBAN structure

Questions such as:

Does the country-specific bank/account portion match the expected shape?

Layer 4: International checksum

Questions such as:

Does MOD-97 return 1?

Layer 5: National rules

Some countries have additional bank-code or account-number checks.

These rules are not identical across all IBAN countries.

Layer 6: Real-world verification

This is outside normal offline IBAN validation.

Questions such as:

Does this bank account exist?
Who owns it?
Can it receive this payment?

usually require a bank, payment provider, directory or verification service.

Why your API should expose validation details

Returning only this:

{
  "valid": true
}

is often not enough.

A more useful response might look like:

{
  "valid": true,
  "country": "DE",
  "lengthValid": true,
  "structureValid": true,
  "checksumValid": true,
  "nationalCheckPerformed": false
}

Now the calling application understands what was actually checked.

That distinction is especially useful when validation coverage differs between countries.

For example:

{
  "checksumValid": true,
  "nationalCheckPerformed": false
}

should not automatically be interpreted as:

everything about this bank account has been verified

It simply means that one additional validation layer was not performed.

Build useful negative test cases

When testing an IBAN validator, don't just use:

asdf

as your invalid example.

Create targeted failure cases.

Start with a known fixture:

DE89 3704 0044 0532 0130 00

Then modify one property at a time.

Wrong checksum

Change one check digit:

DE88 3704 0044 0532 0130 00

Expected result:

checksum failure

Wrong length

Remove one character:

DE89 3704 0044 0532 0130 0

Expected result:

length failure

Invalid characters

Insert an illegal character:

DE89 3704 0044 0532 0130 @0

Expected result:

character or structure failure

Unsupported country

Use an unsupported prefix:

ZZ89...

Expected result:

unsupported country

Testing one failure at a time makes debugging much easier.

Don't confuse a BIC with IBAN validation

Another common misconception is that a BIC automatically verifies an IBAN.

A BIC identifies a financial institution or branch format.

An IBAN identifies an account-format structure.

Even if both strings look syntactically valid, that does not automatically prove that:

this IBAN belongs to this BIC

That relationship requires additional reference data or provider-level verification.

So treat them as separate validation problems unless you explicitly have data linking them.

Don't use random strings as payment test data

If you are building a real payment integration, you normally should not invent arbitrary bank details and attempt to process them.

Use the sandbox or test credentials supplied by your payment provider.

Synthetic IBANs are useful for things like:

form validation
formatting
imports
exports
database fields
UI tests
checksum handling
API schemas

But provider-issued sandbox data should be used for actual payment-flow testing.

A simple IBAN validation pipeline

A practical validation pipeline might look like this:

INPUT
  ↓
Normalize spaces and case
  ↓
Check allowed characters
  ↓
Read country code
  ↓
Check country-specific length
  ↓
Check BBAN structure
  ↓
Run MOD-97
  ↓
Run available national checks
  ↓
Return detailed result

Notice what is not in that pipeline:

Ask bank whether account exists

That is a completely different operation.

Try validation yourself

You can inspect these layers with the Genory IBAN Validator.

It reports country format, length, BBAN structure and MOD-97 results separately rather than treating every successful check as proof of an existing account.

For broader validation tools, Genory also has a dedicated validator collection.

And if you're creating repeatable test cases programmatically, the current developer documentation is available at genory.dev/docs.

A useful rule for your UI

If your software performs offline IBAN validation, avoid messages like:

Account verified

Prefer language such as:

IBAN format is valid

or:

Format and checksum passed

That is more accurate for both developers and users.

Final thought

IBAN validation is a great example of why the word valid can be dangerous in software.

A value can be:

syntactically valid
structurally valid
checksum valid

without being:

a verified real-world bank account

Good validation code does more than return true or false.

It makes clear which claim was actually proven.

UUID v4 vs UUID v7: Which One Should Developers Use in 2026?

Genory Team — Wed, 07 Oct 2026 09:00:00 +0000

UUIDs are everywhere.

They identify users, orders, API resources, database rows, events, uploads and almost anything else that needs a unique ID without relying on a central counter.

For years, UUID v4 has been the obvious default.

Then UUID v7 arrived.

Both produce 128-bit identifiers. Both can work well in distributed systems. But they solve the problem differently — and that difference can matter once your application starts storing millions of records.

So when should you use UUID v4, and when does UUID v7 make more sense?

Let's compare them.

UUID v4 in one sentence

UUID v4 is essentially a randomly generated identifier.

A typical UUID v4 looks like this:

550e8400-e29b-41d4-a716-446655440000

The important property is that independently generated UUIDs have an extremely low probability of colliding.

That makes v4 convenient for distributed systems because multiple services can generate IDs without coordinating with one another.

You don't need:

a central sequence
a database round trip
a shared counter
knowledge of previously generated IDs

Generate one and move on.

Why UUID v4 became so popular

UUID v4 has several attractive properties.

1. It is simple

Most languages and platforms already have mature support for UUID v4.

For example, modern JavaScript can generate one with:

const id = crypto.randomUUID();

console.log(id);

There is very little to configure.

2. Generation is decentralized

Imagine several application servers creating new records at the same time.

With an auto-incrementing integer, the database usually becomes responsible for assigning the next value.

With UUIDs, each server can generate its own identifier before the record even reaches the database.

That is useful for:

distributed systems
offline workflows
event generation
message queues
client-side object creation
microservices

3. IDs do not reveal obvious sequence counts

Consider URLs such as:

/orders/18421
/orders/18422
/orders/18423

Someone can immediately see that the values are sequential.

A UUID looks more like:

/orders/550e8400-e29b-41d4-a716-446655440000

This makes the identifier less predictable.

But an important warning:

An unpredictable identifier is not an authorization mechanism.

Your application must still check whether the current user is allowed to access that resource.

UUIDs are identifiers, not passwords.

The downside of randomness

Randomness is also where UUID v4 can become less attractive for some databases.

Imagine a database index containing identifiers in sorted order.

Now insert these random values:

a82f...
14c9...
f931...
72ab...
09e1...

New records may belong in completely different areas of the index.

Depending on your database, storage engine, index structure and workload, highly random inserts can create more scattered writes than mostly increasing values.

This does not mean:

UUID v4 is always slow.

That would be an oversimplification.

Database behavior depends on many factors:

database engine
UUID storage type
index implementation
page size
write volume
caching
hardware
query patterns

For many applications, UUID v4 performs perfectly well.

But the desire for UUID-style decentralized identifiers that also have useful time ordering is one reason UUID v7 is interesting.

What UUID v7 changes

UUID v7 still gives you a 128-bit UUID, but part of the value represents a Unix timestamp with millisecond precision.

The remaining portion provides randomness.

Conceptually, think of it like:

TIME + RANDOMNESS

rather than:

RANDOMNESS

This gives UUID v7 an important property:

UUIDs generated at different times naturally group by generation time.

A UUID v7 might look like:

0199a4c2-96f8-7b32-a847-84e7f61a66d9

It still looks and behaves like a UUID.

But unlike v4, it contains temporal information.

Why time ordering can be useful

Suppose your application creates these records:

10:00 → record A
10:01 → record B
10:02 → record C
10:03 → record D

UUID v4 values might sort like:

d82...
19a...
f71...
52c...

There is no relationship between lexical order and creation time.

UUID v7 values generated across different milliseconds naturally group more like:

0199a...
0199b...
0199c...
0199d...

This can be useful for systems that create large numbers of records.

Potential use cases include:

event tables
logs
transactions
orders
messages
activity feeds
distributed writes

Time-grouped identifiers can also behave more naturally in some indexed storage workloads.

Again, that does not guarantee that changing from v4 to v7 will magically make your database faster.

Benchmark your actual workload.

UUID v4 vs UUID v7

Here is the practical comparison.

Feature	UUID v4	UUID v7
Main input	Randomness	Timestamp + randomness
Decentralized generation	Yes	Yes
Natural time grouping	No	Yes
Creation time embedded	No	Approximate time
Easy library support	Excellent	Increasing rapidly
Good for generic IDs	Yes	Yes
Useful for time-heavy workloads	Possible	Often attractive
Predictable sequence	No	Time component is observable

Neither is universally better.

They optimize for slightly different priorities.

One subtle limitation: the same millisecond

It is tempting to describe UUID v7 as:

perfectly ordered by creation time

That is not quite correct.

UUID v7 includes a millisecond timestamp.

If several UUIDs are generated during the same millisecond, the timestamp portion can be identical.

Unless the implementation adds a monotonic strategy, their relative ordering inside that millisecond is not guaranteed to represent exact creation order.

So a safer description is:

UUID v7 provides time grouping across milliseconds.

If strict ordering matters, use an explicit timestamp or sequence designed for that requirement.

UUID v7 exposes time information

There is another tradeoff.

UUID v4 does not encode its creation timestamp.

UUID v7 does.

That means someone inspecting a UUID v7 can derive an approximate generation time from it.

For most application IDs, that may be completely acceptable.

But it matters if hiding creation time is part of your threat model.

For example, you may not want publicly exposed identifiers to reveal when a sensitive resource was created.

Again:

Choose an identifier based on your requirements, not because one version is newer.

What about database primary keys?

This is where the debate becomes interesting.

For a new application, you might be choosing between:

BIGINT auto increment
UUID v4
UUID v7

Each has advantages.

Auto-incrementing integers

Advantages:

compact
naturally ordered
excellent database support
easy to debug

Tradeoffs:

usually database-generated
require coordination
expose simple sequence information when public

UUID v4

Advantages:

decentralized
mature
unpredictable
easy to generate almost anywhere

Tradeoffs:

random index distribution
no time information
larger than common integer IDs

UUID v7

Advantages:

decentralized
time-grouped
UUID-compatible
often friendlier to ordered workloads

Tradeoffs:

exposes approximate creation time
newer ecosystem support
not strictly ordered within every millisecond

There is no universal winner.

Store UUIDs properly

Another performance mistake has nothing to do with the UUID version.

It is how the UUID is stored.

A UUID is 128 bits.

Its human-readable representation contains 36 characters:

550e8400-e29b-41d4-a716-446655440000

But storing every UUID as a generic text field is not always necessary.

Many databases provide dedicated UUID types.

For example, PostgreSQL supports:

CREATE TABLE users (
    id UUID PRIMARY KEY
);

Using the database's native UUID type can provide clearer semantics and more efficient storage than treating identifiers as arbitrary strings.

Always check what your database supports.

When I would choose UUID v4

UUID v4 remains a good choice when:

you want maximum ecosystem compatibility
random identifiers are desirable
your current system already uses v4
write ordering is not a concern
you do not want the ID to encode creation time
your database workload already performs well

There is little reason to migrate a working application from v4 solely because v7 exists.

When I would choose UUID v7

For a new application, I would seriously consider UUID v7 when:

records are frequently inserted
time grouping is useful
IDs are stored in indexed database columns
multiple services generate identifiers
you want sortable UUID-style identifiers
exposing approximate creation time is acceptable

This is particularly interesting for systems dealing with large chronological datasets.

Think:

events
messages
orders
logs
audit records
transactions

Don't use UUIDs as secrets

This deserves repeating.

Neither UUID v4 nor UUID v7 should replace proper secrets.

Do not treat a UUID as equivalent to:

an API key
session token
password-reset token
authentication token
authorization rule

Even when an identifier is difficult to guess, your application should still enforce access control.

Use cryptographically appropriate tokens for security-sensitive purposes.

Try both versions

Sometimes the easiest way to understand the difference is simply to generate both.

You can compare UUID v4 and v7 using the Genory UUID Generator.

Generate several v4 values and notice how unrelated they appear.

Then generate several v7 values and compare identifiers created at different times.

Genory also exposes UUID generation through its developer API. For supported API access, the current documentation is available at genory.dev/docs.

Conceptually, the API supports choosing the UUID version:

version = v4

or:

version = v7

That makes it easy to test how both identifier strategies behave in your own fixtures before making an architectural decision.

So which one should you use in 2026?

For an existing system successfully using UUID v4:

Keep using v4 unless you have a concrete reason to change.

For a new application where UUIDs will become heavily indexed database keys:

UUID v7 deserves serious consideration.

For identifiers where you do not want to reveal approximate creation time:

UUID v4 may be preferable.

For systems where chronological grouping is useful:

UUID v7 is often the more interesting choice.

The most important rule is not:

Always use the newest UUID version.

It is:

Understand what information your identifier contains and how your storage system will use it.

Final thought

UUID v4 solved an important distributed-systems problem extremely well.

UUID v7 does not replace it.

Instead, v7 adds something many modern applications can benefit from: time-aware ordering without giving up decentralized UUID generation.

That makes the decision surprisingly simple:

Use v4 when randomness is exactly what you need.

Use v7 when time grouping gives your system an advantage.

And if performance is the reason you're choosing between them, benchmark your own database instead of trusting a rule of thumb.

How to Generate Realistic Test Data Without Using Real Customer Data

Genory Team — Mon, 05 Oct 2026 09:00:27 +0000

Realistic test data is one of those things that seems simple until you actually need it.

A signup form might only require a name and an email address. But a real application often needs much more:

names
addresses
phone numbers
dates
UUIDs
company information
account-format data
custom fields
relationships between fields

The obvious shortcut is to copy a few rows from production.

That is also one of the worst habits a development team can build.

In this article, we'll look at a safer and more useful approach: generating synthetic test data designed specifically for development and QA.

Why production data should stay out of your test environment

Using real customer information may make test data look realistic, but it introduces unnecessary risk.

Development, staging and demo environments often have different security controls than production. Data may end up in:

local databases
screenshots
bug reports
log files
test exports
developer laptops
temporary environments

A much better principle is:

Test the structure and behavior of your application without copying the people behind the data.

Synthetic test data gives you values that resemble the data your application expects while remaining independent from actual customer records.

Random data is not always good test data

Generating random strings is easy.

Generating useful test data is harder.

Consider an address form.

This is technically random:

Name: Xkqpd Azzw
City: 48291
Phone: foo-bar

But it doesn't help much when testing a real user interface.

A more useful fixture might look like:

Name: Anna Schneider
Email: anna.schneider@example.com
Country: DE
City: Hamburg
Postal code: 20095

The goal is not to create a real person.

The goal is to produce data that behaves like the type of input your application is designed to process.

Keep related fields related

One common mistake is generating every column independently.

Imagine this row:

{
  "country": "DE",
  "postalCode": "SW1A 1AA",
  "phone": "+81...",
  "city": "Toronto"
}

Every individual value may look plausible, but the record as a whole is useless for many tests.

For profile-style fixtures, related fields should share context.

Names, addresses, phone formats and country settings should make sense together whenever your test actually depends on that relationship.

For tests where relationships don't matter, you can deliberately generate fields independently.

The important part is making that choice intentionally.

Use reserved domains for test email addresses

Email addresses are another surprisingly easy source of trouble.

Avoid generating random addresses on real domains such as:

randomperson@gmail.com

You don't know whether that address actually belongs to someone.

For test fixtures, domains such as example.com are much safer:

maria.schmidt@example.com

They clearly communicate that the address is test data and avoid accidentally involving real users.

Make test datasets reproducible

Random data is useful for exploration.

Repeatable data is useful for debugging.

Suppose a test fails only when a particular dataset is generated. If every execution creates completely different values, reproducing the problem becomes harder.

A seeded generator solves this.

Conceptually:

seed = checkout-regression-42

Using the same generator configuration and seed can reproduce the same dataset.

This is especially useful for:

regression tests
imports
API fixtures
UI snapshots
bug reproduction
CI pipelines

Use random datasets when you want variation.

Use seeded datasets when you want repeatability.

Test boundaries, not just happy paths

Synthetic data becomes much more valuable when you stop treating it as filler.

Instead, design datasets around scenarios.

For example:

Scenario 1: normal signup
Scenario 2: very long name
Scenario 3: missing optional address field
Scenario 4: minimum allowed number
Scenario 5: maximum allowed number
Scenario 6: leap-day date
Scenario 7: duplicate identifier

The best test dataset is rarely the largest one.

It is the dataset that deliberately exercises the assumptions in your application.

Structured identifiers need special handling

Some values have rules beyond simple formatting.

Examples include:

UUIDs
IBANs
card-number formats
IMEI numbers
MAC addresses

For these, a random string with the right length is often not enough.

A UUID should follow the appropriate UUID format.

An IBAN used to test a validator may need the correct country structure and checksum.

A card-number fixture may need to satisfy the Luhn algorithm.

That still does not mean the generated value represents a real account, device or payment method.

Format validity and real-world existence are two completely different things.

Generate only the fields you need

Another mistake is generating huge fake profiles for every test.

If you're testing an import with these columns:

customer_name
email
order_total
status

you probably don't need:

phone
street
company
job_title
iban
username
date_of_birth

Smaller datasets are easier to understand and debug.

A schema-first approach works well:

[
  { "name": "customer", "type": "fullName" },
  { "name": "email", "type": "email" },
  { "name": "total", "type": "decimal" },
  { "name": "status", "type": "choice" }
]

Generate the minimum dataset that exercises the behavior you want to test.

Automate test-data generation when it makes sense

Manual generators are useful while developing and exploring.

Once a test-data workflow becomes repetitive, an API can be more practical.

For example, a profile request could look like this:

curl --request POST "https://genory.dev/api/profile" \
  --header "Authorization: Bearer $GENORY_API_KEY" \
  --header "Content-Type: application/json" \
  --data '{
    "country": "DE",
    "amount": 1,
    "fields": ["firstName", "lastName", "email"]
  }'

Now a fixture can be generated from a script, CI job or development tool instead of being copied manually.

Whatever service you use, keep API keys in environment variables or a secret manager rather than committing them to your repository.

A practical workflow

A simple process works surprisingly well:

Define the behavior you want to test.
Decide which fields actually matter.
Choose the country or format constraints.
Add edge cases intentionally.
Use synthetic rather than production data.
Use a seed when reproducibility matters.
Generate a small dataset first.
Scale only when the small test works.

For quick experiments, you can build synthetic profiles and custom datasets with Genory.

Genory includes a Test Data Generator, schema-based dataset tools, UUID utilities and format-specific generators.

If you're automating the process, the current API reference is available in the Genory developer documentation.

Final thought

Good test data isn't data that looks impressive.

It's data that exposes assumptions.

Synthetic data gives developers a way to build realistic fixtures without turning production customer information into development material.

Generate less data, make it intentional, and design every dataset around the behavior you're actually trying to test.