Mock Data Generator

Mock Data: The Foundation of Reliable Development

Every non-trivial software project needs realistic test data, for development databases, demo environments, unit tests, performance benchmarks, and design reviews. The two bad options are (1) using real production data (privacy risk, slow, brittle) or (2) hand-typing fake records (tedious, inconsistent, sparse). The third option, generating realistic mock data on demand, is what this tool does.

Why Realistic Mock Data Matters

Mock data isn't just placeholder content. Quality of test data directly affects:

• UI design. A user list with names like 'AAA AAA AAA' and 'BBB BBB BBB' tells you nothing about how the design handles real names. Realistic names ('Margaret Anderson-Quinones', 'Sven Lindqvist') stress-test layout, truncation, and accessibility.
• Form validation. Real names contain apostrophes, hyphens, accents, and spaces. Real addresses span 5–7 lines. Real phone numbers vary in format by country. Mock data that covers this diversity reveals validation bugs early.
• Edge cases. Realistic data exposes the long tail of bugs, what happens to a user named 'O'Brien' in your SQL queries? What about 'Müller' through your URL encoder? Diverse mock data forces these questions.
• Performance testing. 10 hand-typed records won't reveal that your search query degrades quadratically. 50,000 mock records will.
• Demo experience. A demo with 'John Smith' x 20 looks fake. A demo with diverse, realistic records looks like a real product.

The Schemas

Common business-domain shapes the tool can generate:

1. User profiles. First name, last name, full name, email, phone, address (street/city/state/postal/country), date of birth, role (admin/user/guest), avatar URL, created date. Fields are internally consistent: the email matches the name, the city/state/postal align geographically, the avatar is a placeholder image URL.

2. Products. SKU, product name, description, category, price, currency, in-stock count, weight, dimensions, supplier. Names follow plausible patterns ('Premium Wireless Headphones', 'Organic Cotton T-Shirt'); prices fall in reasonable ranges per category.

3. Blog posts. Title, slug, body (lorem-ipsum or generated text), author, tags, publish date, status (draft/published/archived). Slugs match titles; publish dates are in the past; authors are consistent across multiple posts (one author can have several posts).

4. Transactions. ID, amount, currency, status (pending/completed/refunded/failed), payment method, timestamp, customer reference. Status-dependent fields populate appropriately, refunded transactions have refund timestamps; failed ones have error codes.

5. Events. Event name, location, start/end timestamps, capacity, organizer, type (meetup/workshop/conference). Times are plausibly in the future; durations are sensible (a workshop is hours, a conference is days).

Internal Consistency: The Quality Differentiator

Cheap mock data uses independent random fields. A user with first name 'Jane' might have email 'bob123@x.com' and live in a city that doesn't exist in their state. This breaks suspended disbelief in demos and creates flaky test scenarios.

Quality mock data uses consistency rules:

• Name → email match. Jane Smith gets jane.smith@example.com or j.smith@example.org.
• City/state/postal form valid geographic units.
• Date ordering. created_at < updated_at; published posts have past dates; events have future dates; people aren't born in 2030.
• Status-dependent fields. Refunded transactions have refund details; pending ones don't.
• Cross-record relationships. A blog post's author exists in the user list; an order's products exist in the product list.

This tool's generators follow these rules by default. If you need stricter relationships across generated records (e.g., 'every order references a real user'), generate users first and use their IDs when generating orders.

Privacy: Why Not Use Anonymized Real Data?

Anonymization is harder than it sounds. The Netflix Prize dataset (released anonymized in 2006) was de-anonymized by cross-referencing with IMDB ratings, researchers could identify specific users from their movie preferences. The lesson: 'anonymized' data often isn't, when combined with other data sources.

Mock data has no such risk because no real person is involved. The names are random; the emails are non-routable; the addresses are constructed. You can put a 100,000-record mock database on a developer's laptop with zero privacy concerns.

The downside: mock data doesn't have the same statistical properties as real data. Your fraud detection model trained on mock data won't catch real fraud patterns. For ML training, you usually need real (or synthetic-but-distributionally-matched) data.

Reserved Test Domains and Numbers

The tool uses RFC 2606 reserved domains:

• example.com, example.org, example.net, guaranteed never to be assigned.
• .test, .example, .invalid, .localhost, guaranteed never to be a real TLD.

Phone numbers use the 555 prefix in North American format (used in movies precisely because they're reserved). International phone numbers use ranges marked as non-assigned by the ITU.

You can paste mock data into form testing without worry, no real person receives the email, no real phone rings.

Common Workflows

1. Seeding a dev database. Generate 1,000 users, 10,000 products, 50,000 orders; paste into seed scripts. Dev environment immediately feels like a real product.
2. Storybook / component library. Each story uses fresh mock data, designers see how components handle realistic content variation.
3. API contract testing. Mock the API response with this tool; write tests against the mock; replace mock with real API once it exists.
4. Load testing. Generate 100,000 records; bulk-import into the test environment; benchmark.
5. Demo data refresh. Sales demo needs fresh-looking data each quarter; regenerate the database from mock generators.
6. UI design review. Designer reviews 'how does this list look with 20 realistic names?' instead of 'Lorem Ipsum 1 / 2 / 3'.

When Mock Data Isn't Enough

• i18n testing. Mock data is usually Latin-script. For full i18n, generate names with multi-byte UTF-8 (Chinese, Arabic, Cyrillic) explicitly.
• Date boundary bugs. Random dates may not hit DST transitions, leap years, or month-end boundaries. For these, use specific test fixtures.
• Validation edge cases. Test cases like 'maximum-length name' or 'name with only spaces' need explicit construction, not random generation.

In real projects, mock data covers 80% of testing needs; the remaining 20% are hand-crafted fixtures.

Privacy

Generation runs entirely in your browser. Lookup tables (first names, last names, cities) are bundled JS data. No telemetry on what schemas you generate or how much. Safe for proprietary projects.