E-Commerce Test Data: Products, Orders & More

Building an e-commerce application means juggling interconnected data: customers place orders, orders contain line items, and line items reference products. Testing any one of those entities in isolation is easy. Testing them together — with realistic foreign key relationships, plausible price totals, and edge cases like empty carts or guest checkouts — is where most teams waste hours writing fixtures by hand.

This page provides a complete, ready-to-use e-commerce test dataset. Each table below is generated by our Mock Data Generator with deterministic seeds, so the output is reproducible. Click Regenerate for fresh values, Copy to grab the JSON, or Download to save the file. For a fully connected relational dataset with enforced foreign keys, use the relational tab in the Mock Generator — it includes a one-click e-commerce preset.

The E-Commerce Data Model

Even the simplest storefront needs at least four entities. Understanding how they relate is the first step toward writing meaningful tests:

• Customers — people who create accounts, browse products, and place orders. A customer has a unique email, contact details, and a signup date.
• Products — items available for purchase. Each product has a name, description, price, and category.
• Orders — a purchase event tied to a customer. An order has a date, a total amount, and a status (pending, shipped, delivered, refunded).
• Order Items — the individual line items within an order. Each references a product and records the quantity and unit price at the time of purchase.

In a production database, foreign keys enforce these relationships: orders.customer_email references customers.email, and order_items.product_name references products.name. Our relational builder in the Mock Generator preserves this referential integrity automatically, so child rows always point to valid parent records.

Customers

The customer table is the foundation. Every order traces back to a customer record, and most e-commerce platforms use the email address as the primary identifier for login, receipts, and marketing. This schema generates unique emails and realistic names, phone numbers, and cities.

What to test with this data: user registration flows, duplicate email detection, profile update forms, customer search and filtering, and account deletion (GDPR right-to-erasure). Pay attention to names that contain apostrophes or hyphens — they break naive string validation more often than you would expect.

Products

Product data drives catalog pages, search results, shopping carts, and recommendation engines. This schema includes product names, multi-sentence descriptions, decimal prices, and categories. The generated prices use realistic decimal values rather than round numbers, which is important for testing currency formatting and tax calculations.

What to test with this data: product listing pages with sorting and filtering, search indexing, price display with locale-specific formatting ($1,299.99 vs 1.299,99 EUR), inventory management, and category-based navigation. Use the JSON Formatter to validate and pretty-print the output before importing it into your application.

Orders

Orders are where the complexity lives. Each order ties a customer to a set of line items, carries a total, and transitions through statuses over its lifecycle. The status field here generates category-style strings — in practice, you would map these to your own status enum (pending, processing, shipped, delivered, cancelled, refunded).

What to test with this data: order creation and checkout flows, order history pages, status transition logic (can a "delivered" order be cancelled?), email notification triggers, admin order management dashboards, and reporting queries that aggregate revenue by date or status.

Order Items

Order items (also called line items) represent the individual products within an order. Each row records what was purchased, how many, and at what price. The unit_price is captured at order time because product prices change — a common source of bugs when developers reference the current product price instead of the historical one.

What to test with this data: line item subtotal calculations (quantity * unit_price), order total validation (sum of line items should match order total), cart modification (add, remove, update quantity), inventory deduction on purchase, and return/refund flows that need to credit specific line items.

Testing Edge Cases

Realistic-looking data is a starting point, but the bugs that reach production usually hide in the edge cases. Here are scenarios every e-commerce test suite should cover:

Empty and Minimal States

What happens when a customer has zero orders? When an order has zero line items (empty cart submitted)? When a product has no description? These "empty state" scenarios are the first things QA finds and the last things developers remember to test. Generate a dataset with nullablePercent set to 20-30% in the Mock Generator to simulate missing fields.

Refunds and Cancellations

Refund logic is notoriously tricky. Test partial refunds (one of three items returned), full refunds, refunds after a payment provider webhook delay, and double-refund prevention. Your test data needs orders in every status, including edge states like "refund pending" and "partially refunded."

Multi-Currency and Internationalization

If your store serves multiple regions, test with prices in different currencies. Watch for floating-point rounding errors in currency conversion — 0.1 + 0.2 !== 0.3 in JavaScript. Use integer cents internally and format for display. The Mock Generator's locale support lets you generate region-specific names and addresses alongside your price data.

Inventory and Out-of-Stock

Generate products with a stock_quantity of zero to test out-of-stock handling: can a customer add it to their cart? Does checkout block correctly? Does a race condition allow overselling when two customers check out simultaneously?

Guest Checkout

Many stores allow purchasing without an account. Test orders where customer_email does not match any record in the customers table — this is a valid state in guest checkout flows and should not cause foreign key violations if your schema supports it.

Using This Data

Once you have your e-commerce datasets, here are the most common ways to put them to work:

Database Seeding

Import the JSON directly into your ORM's seed script, or switch the export format to SQL for raw INSERT statements. Our Database Seeding Guide walks through this for PostgreSQL, MySQL, and SQLite with complete code examples.

API Mocking

Use the generated data as stub responses for your frontend while the backend is still in development. Wrap each dataset in your API's response envelope (pagination metadata, status codes, rate limit headers) and serve it from a mock server or msw (Mock Service Worker).

Load Testing

Generate thousands of rows (the Mock Generator supports up to 10,000 per table) and feed them into load testing tools like k6, Artillery, or Locust. Realistic data distributions — varied product categories, mixed order statuses, geographically diverse customers — produce more meaningful performance results than uniform synthetic data.

Demo Environments

Sales demos and staging environments need data that looks convincing. A storefront populated with "Test Product 1" and "user@example.com" undermines credibility. Deterministic seeds ensure your demo data is consistent across deploys while still looking natural.

Exporting as SQL

Every dataset on this page can be exported as SQL INSERT statements — just switch the format in the Mock Generator or use the toolbar above each block. The SQL export generates standard INSERT INTO syntax compatible with PostgreSQL, MySQL, and SQLite, with proper type inference for UUIDs, timestamps, and decimal prices.

For a detailed walkthrough of seeding your database from generated data — including handling auto-incrementing IDs, foreign key ordering, and transaction wrapping — see the Database Seeding Guide.

Building Connected Datasets with the Relational Builder

The individual tables above are useful, but a real e-commerce test suite needs data where the relationships are enforced. The Mock Generator's relational tab lets you define multiple tables with explicit foreign key constraints. When you generate the data, child rows automatically reference valid parent records — no manual stitching required.

The relational builder includes a pre-built e-commerce preset that creates all four tables (customers, products, orders, order items) with foreign keys already wired. Select it from the preset dropdown and hit Generate to get a complete, referentially consistent dataset in seconds.