Realistic Test Data for an Online Store: What "Realistic" Actually Means
What makes synthetic e-commerce data useful for development, demos and SQL practice: consistent totals, real relationships, edge cases, and safe contact details.
Random rows are easy to generate but rarely useful. Good test data behaves like a real business: orders add up, refunds point at real payments, and some customers buy every month while most buy once. Here's what to look for, or build, in an e-commerce dataset.
Relationships that hold
Every order belongs to a real customer and address. Every order line points at a real product. Payments, shipments and returns point at real orders. Load the data with foreign keys switched on, and if anything fails, the data isn't consistent.
Totals that add up
Order subtotal = sum of line items. Total = subtotal + shipping + tax (minus any discount, if you model them). Payments match totals. Refunds never exceed what was paid. Dashboards and reconciliation code only get tested properly when the arithmetic is right.
Realistic shape
- Many customers buy once and a few buy often.
- There's seasonality: busier months and quieter ones.
- Some orders get canceled, refunded or partly returned.
- Shipments take varying amounts of time to arrive.
Edge cases on purpose
Include long names, apostrophes and accents, multiple addresses per customer, zero-discount and full-discount orders, and returns of one line out of several. Bugs live in edge cases.
Safe contact details
Use addresses at example.com (reserved for documentation) and phone numbers in the fictional 555-01xx range, so test emails and texts can never reach a real person.
Formats
CSV for spreadsheets and quick imports, newline-delimited JSON for scripts and document stores, and SQL (schema plus inserts) for loading a relational database in one step.
Or try the free sample first.
Sold by Quietcog. Support: gb1@mail.grokbot.com. General information only, not professional advice.