iLoveDevToolThree sources of test data
There are three ways to fill a test environment with data: sanitize production data (compliance-heavy, and incomplete sanitization is an incident), generate with a programming library (faker.js et al — flexible but requires code), and use an online generator (paste and get). For low-frequency and one-off tasks — seeding a local dev database, dressing up a demo environment, mocking an API response — the third path costs the least.
This guide covers the field rules and format practice for online generation, so the data comes out shape-real, harmless, and format-correct.
Field types: shape-real is enough
The first principle of fake data is shape-real, content harmless — each field preserves its shape:
- Names: Zhang San everywhere is the old English-faker problem in Chinese systems — Chinese systems should use Chinese names (surname + given name, natural two-to-four character lengths)
- Email:
user@example.comis the RFC 2606 reserved-domain form, good for documentation examples; data generation more often uses random combinations over real domains (shaped like real inboxes) — but remember they may coincide with real addresses: placeholder only, never send mail - Phone: what's preserved is the 1[3-9]-prefixed 11-digit shape; random combinations may hit numbers in active use — placeholder only
- City/company: drawn from common pools — natural shape, no need for real administrative divisions
- Numbers: ranges matter — order amounts of 0-1000 and points of 0-10^7 are different worlds; min/max is part of the field definition
- Dates: see the pitfalls below
The safety boundary: what to do and what not to
Not every generatable field should be generated. The test: can the output pass a real verification flow?
| Field | Verification scenario | Verdict |
|---|---|---|
| Name / city / company | none | do it |
| Email / phone | shape check (not real-name) | do it (placeholder risk manageable) |
| ID card / bank card / passport | checksum algorithms, passes real-name pre-screens | don't |
A fake ID generated to pass its checksum algorithm is "validly shaped" — it clears front-end validation and some real-name pre-screens, with substantive misuse risk. That's the boundary line for a responsible fake-data tool.
The classic pitfall of random dates
The easiest way to get "random dates in 2020-2025" wrong is randomizing year, month, and day independently — that's how 2023-02-30 happens. The correct approach is the day-of-year method: randomize an offset within the range's day span, add it to the start date, then format. Leap years and month lengths come out right automatically.
Boundaries must be pinned too: whether "2020 to 2025" includes the endpoints — one day off fails a test assertion.
Practice for the three output formats
JSON: fixtures and mock APIs
An array of objects is the most universal shape — unit-test fixtures and mock-server responses consume it directly. Chinese values don't need \uXXXX escaping — modern toolchains are UTF-8-native and readability wins.
CSV: spreadsheets and import tools
RFC 4180 is the floor: values containing commas, quotes, or line breaks get quoted with internal quotes doubled. Numbers and booleans stay unquoted — quoting them turns everything into strings downstream (for example, a CSV-to-JSON tool's dynamic typing).
SQL: straight into the database
Complete SQL output includes CREATE TABLE (column types derived from field types: integers INT, dates DATE, the rest VARCHAR) and batched INSERTs. Two easy misses: column names need sanitizing (user input like order/user breaks the create statement as reserved words) and single quotes in values need '' escaping. For prettier output, run the result through a SQL formatter.
From schema to data
The mock data generator implements all the rules above: 11 field types defined row by row (numeric ranges included), a preset user-table schema in one click, 1-1000 rows generated live, output in JSON/CSV/SQL (SQL includes table creation and escaping), and Chinese/English dataset switching — Chinese systems no longer get awkward English-faker output, and everything runs in the browser. Check generated JSON with the JSON formatter and tidy SQL with the SQL formatter — the whole workflow from making data to using it, one stop apart.
Frequently Asked Questions
Which field types are common for fake test data?
The mainstream eleven: name, username, email, phone, city, company, integer, decimal, date, UUID, and boolean — covering the common columns of user and order tables. More complex fields (full addresses, coordinates, nested structures) can be composed from these base types or added by post-processing.
Why should ID-card numbers never be generated by tools?
ID numbers carry checksum algorithms: a fake number generated to pass the GB 11643 checksum clears most front-end format checks and even some real-name API pre-screens — such "validly shaped" fake IDs carry a substantive risk of misuse in registration and fraud, so responsible tools don't offer them. Phone numbers have no checksum scenario and are only shape-real, keeping placeholder risk manageable — that is the line between doing and not doing.
Is JSON, CSV, or SQL the best output for fake data?
Depends on use: JSON goes straight into unit-test fixtures or mock API responses; CSV pastes into spreadsheets and data-import tools; SQL (create table + inserts) fits pouring data into a database — one run of INSERTs gives a dev database a thousand rows. The escaping rules differ per format (CSV needs comma/quote handling, SQL needs single-quote and reserved-word handling), so picking the right format beats hand-escaping.
What are the pitfalls of random date generation?
The classic bug is randomizing year, month, and day independently — that produces February 30th. The correct approach is to randomize a day offset within the range and format from the start date (the day-of-year approach); leap years come out right automatically. The second pitfall is boundary ambiguity: "2020 to 2025" must state whether the endpoints are included — one day off fails a test assertion.