How to create mock data for testing

STEP 1

Define the smallest useful data model

Begin with the workflow under test, not with every field your database contains. A registration form might need only an email, password, display name, and account state. A shipping flow needs an address and country rules. Smaller fixtures are easier to understand when a test fails.

STEP 2

Use fictional values that cannot be mistaken for customers

Mock data should preserve structure without impersonating a real person. Use the reserved example.com domain for email addresses, clearly synthetic IDs, masked payment displays, and non-sensitive values. Do not generate usable card numbers, passwords for real accounts, or documents intended to pass verification.

{
  "id": "MDK-408-0001",
  "name": "Nora Shah",
  "email": "nora.shah@example.com",
  "masked_card": "•••• •••• •••• 1842",
  "active": true
}

STEP 3

Add realism and deliberate edge cases

Perfectly uniform records hide defects. Include a normal baseline dataset and then create focused edge-case fixtures. Useful variations include long names, Unicode characters, optional blanks, boundary dates, inactive accounts, different country formats, and text that challenges narrow layouts.

Useful realism is internally consistent. A Canadian address should use a Canadian province and postal-code shape; random pieces from different locales can test the wrong thing.

STEP 4

Make random generation repeatable

A fixed numeric seed turns pseudo-random generation into a reproducible fixture. Save the seed beside the test configuration. When a failure occurs, another developer can generate the same rows instead of trying to reproduce an unknown random state.

STEP 5

Choose the format your workflow already expects

Switching formats should not generate new values. Review the same underlying records in each representation so the test remains consistent.

STEP 6

Validate the fixture before trusting the test

Check types, required fields, unique identifiers, relationships, locale formatting, and row count. Confirm that CSV values are safely quoted, SQL strings are escaped, and JSON matches the consumer’s expected shape. Generated data can expose application behavior, but it does not replace validation of your generator and test assumptions.