Test Data Generation
Table of Contents
Overview
Test data generation creates realistic, consistent, and maintainable test data for automated testing. Well-designed test data reduces test brittleness, improves readability, and makes it easier to create diverse test scenarios.
When to Use
- Creating fixtures for integration tests
- Generating fake data for development databases
- Building test data with complex relationships
- Creating realistic user inputs for testing
- Seeding test databases
- Generating edge cases and boundary values
- Building reusable test data factories
Quick Start
Minimal working example:
// tests/factories/userFactory.js
const { faker } = require("@faker-js/faker");
class UserFactory {
static build(overrides = {}) {
return {
id: faker.string.uuid(),
email: faker.internet.email(),
firstName: faker.person.firstName(),
lastName: faker.person.lastName(),
age: faker.number.int({ min: 18, max: 80 }),
phone: faker.phone.number(),
address: {
street: faker.location.streetAddress(),
city: faker.location.city(),
state: faker.location.state(),
zip: faker.location.zipCode(),
country: "USA",
},
role: "user",
isActive: true,
createdAt: faker.date.past(),
...overrides,
};
}
// ... (see reference guides for full implementation)
Reference Guides
Detailed implementations in the references/ directory:
| Guide |
Contents |
| Factory Pattern for Test Data |
Factory Pattern for Test Data |
| Builder Pattern for Complex Objects |
Builder Pattern for Complex Objects |
| Fixtures for Integration Tests |
Fixtures for Integration Tests |
| Realistic Data Generation |
Realistic Data Generation |
Best Practices
✅ DO
- Use faker libraries for realistic data
- Create reusable factories for common objects
- Make factories flexible with overrides
- Generate unique values where needed (emails, IDs)
- Use builders for complex object construction
- Create fixtures for integration test setup
- Generate edge cases (empty strings, nulls, boundaries)
- Keep test data deterministic when possible
❌ DON'T
- Hardcode test data in multiple places
- Use production data in tests
- Generate truly random data for reproducible tests
- Create overly complex factory hierarchies
- Ignore data relationships and constraints
- Generate massive datasets for simple tests
- Forget to clean up generated data
- Use the same test data for all tests
1---2name: test-data-generation3description: Generate realistic, consistent test data using factories, fixtures, and fake data libraries. Use for test data, fixtures, mock data, faker, test builders, and seed data generation.4---5
6# Test Data Generation
7
8## Table of Contents
9
10- [Overview](#overview)
11- [When to Use](#when-to-use)
12- [Quick Start](#quick-start)
13- [Reference Guides](#reference-guides)
14- [Best Practices](#best-practices)
15
16## Overview
17
18Test data generation creates realistic, consistent, and maintainable test data for automated testing. Well-designed test data reduces test brittleness, improves readability, and makes it easier to create diverse test scenarios.
19
20## When to Use
21
22- Creating fixtures for integration tests
23- Generating fake data for development databases
24- Building test data with complex relationships
25- Creating realistic user inputs for testing
26- Seeding test databases
27- Generating edge cases and boundary values
28- Building reusable test data factories
29
30## Quick Start
31
32Minimal working example:
33
34```javascript
35// tests/factories/userFactory.js
36const { faker } = require("@faker-js/faker");
37
38class UserFactory {
39 static build(overrides = {}) {
40 return {
41 id: faker.string.uuid(),
42 email: faker.internet.email(),
43 firstName: faker.person.firstName(),
44 lastName: faker.person.lastName(),
45 age: faker.number.int({ min: 18, max: 80 }),
46 phone: faker.phone.number(),
47 address: {
48 street: faker.location.streetAddress(),
49 city: faker.location.city(),
50 state: faker.location.state(),
51 zip: faker.location.zipCode(),
52 country: "USA",
53 },
54 role: "user",
55 isActive: true,
56 createdAt: faker.date.past(),
57 ...overrides,
58 };
59 }
60// ... (see reference guides for full implementation)
61```
62
63## Reference Guides
64
65Detailed implementations in the `references/` directory:
66
67| Guide | Contents |
68|---|---|
69| [Factory Pattern for Test Data](references/factory-pattern-for-test-data.md) | Factory Pattern for Test Data |
70| [Builder Pattern for Complex Objects](references/builder-pattern-for-complex-objects.md) | Builder Pattern for Complex Objects |
71| [Fixtures for Integration Tests](references/fixtures-for-integration-tests.md) | Fixtures for Integration Tests |
72| [Realistic Data Generation](references/realistic-data-generation.md) | Realistic Data Generation |
73
74## Best Practices
75
76### ✅ DO
77
78- Use faker libraries for realistic data
79- Create reusable factories for common objects
80- Make factories flexible with overrides
81- Generate unique values where needed (emails, IDs)
82- Use builders for complex object construction
83- Create fixtures for integration test setup
84- Generate edge cases (empty strings, nulls, boundaries)
85- Keep test data deterministic when possible
86
87### ❌ DON'T
88
89- Hardcode test data in multiple places
90- Use production data in tests
91- Generate truly random data for reproducible tests
92- Create overly complex factory hierarchies
93- Ignore data relationships and constraints
94- Generate massive datasets for simple tests
95- Forget to clean up generated data
96- Use the same test data for all tests