Testing E-commerce at Scale: Why 6,900+ Tests Matter

A marketing website can survive a broken contact form for a few hours. An e-commerce platform cannot survive a payment bug for five minutes.

When we built CardDeckr, a custom card game marketplace connecting independent designers with print manufacturers, we knew that every transaction, every inventory update, and every Stripe webhook had to work perfectly, every time. A single bug in the checkout flow could mean lost revenue, double-billed customers, or inventory sync failures that cascade across the entire platform.

That is why CardDeckr now runs on a suite of 6,900+ automated tests that verify every critical path before a single line of code ships to production. This is not over-engineering. This is the minimum viable safety net for a platform where money changes hands.

If you are building or considering custom e-commerce software, understanding why comprehensive testing matters, and what it actually looks like in practice, will save you from expensive mistakes down the line.

Why E-commerce Platforms Need More Testing Than Marketing Sites

A marketing website has a handful of critical paths: load the page, submit the contact form, maybe process a newsletter signup. If something breaks, the impact is limited. A visitor might bounce, or an enquiry might be lost. Annoying, yes. Catastrophic, no.

An e-commerce platform has hundreds of critical paths, all of which involve money, inventory, or customer data. Every one of them must work correctly under load, across different user states, and in the correct sequence.

Here is what breaks when e-commerce testing is insufficient:

Payment flows: Customer pays, but the order never confirms. Or worse, they are charged twice because a retry mechanism fires incorrectly.
Inventory sync: A product shows as in stock when it is not. Customer buys it. Manufacturer cannot fulfil it. Refund issued, customer lost.
Stripe webhooks: A subscription renewal fails but the webhook never fires, so the platform never cancels access. Free service for paying customers sounds great until you realise you are haemorrhaging revenue.
Data integrity across tables: A user deletes their account, but their orders remain orphaned in the database. Now your reporting is wrong, your analytics are skewed, and your GDPR compliance is questionable.
Edge cases in discount logic: A coupon code stacks with another promotion incorrectly, giving customers 150% off instead of 50% off. You lose money on every sale.

These are not hypothetical. These are real bugs we have seen in production e-commerce platforms that did not have adequate test coverage. The cost of fixing them after launch is orders of magnitude higher than the cost of writing tests upfront.

The Testing Pyramid for E-commerce Platforms

Not all tests are created equal. A well-structured test suite follows the testing pyramid: lots of fast unit tests at the base, fewer integration tests in the middle, and a small number of end-to-end tests at the top.

Here is how that breaks down for a platform like CardDeckr:

Unit Tests (Base Layer)

What they test: Individual functions, utilities, and business logic in isolation.

Examples from CardDeckr:

Price calculation logic (base price + modifiers + discounts)
Tax calculation for different regions
Coupon validation rules (expiry, usage limits, minimum order value)
Inventory availability checks
Order status state transitions (pending → confirmed → printing → shipped)

Why they matter: Unit tests are fast (milliseconds), easy to write, and cover the majority of your codebase. When a unit test fails, you know exactly which function broke. They form the foundation of deployment confidence.

CardDeckr has thousands of unit tests covering every pricing rule, every discount scenario, and every inventory calculation. When we refactor pricing logic, we know immediately if something breaks.

Integration Tests (Middle Layer)

What they test: How different parts of the system work together, including database queries, API endpoints, and third-party service integrations.

Examples from CardDeckr:

Stripe payment intent creation and confirmation flows
Order creation that spans multiple database tables (users, orders, order_items, inventory)
Manufacturer API calls to submit print jobs
Email notification triggers after order state changes
Webhook handlers for Stripe subscription events (payment_succeeded, payment_failed, customer.subscription.deleted)

Why they matter: Integration tests catch bugs that only appear when components interact. A price calculation function might work perfectly in isolation, but fail when combined with a discount code and a Stripe payment intent. Integration tests catch those failures before production.

CardDeckr’s integration tests verify that when a customer completes checkout, the correct sequence fires: payment captured, order created, inventory decremented, manufacturer notified, confirmation email sent. If any step fails, the test fails.

End-to-End Tests (Top Layer)

What they test: Full user journeys through the application, from browser to backend to database.

Examples from CardDeckr:

Complete checkout flow: add to cart → enter details → pay with Stripe → receive confirmation
Designer onboarding: create account → upload card design → submit for review → get approved → publish listing
Manufacturer portal: receive order → mark as printing → upload proof → mark as shipped

Why they matter: End-to-end tests verify that the entire platform works as a cohesive system. But they are slow (seconds or minutes), brittle (prone to flakiness), and expensive to maintain. Use them sparingly for critical user flows only.

CardDeckr runs a lean set of end-to-end tests covering the three most critical paths: checkout, designer onboarding, and order fulfilment. Everything else is covered by faster unit and integration tests.

How CardDeckr’s 6,900+ Tests Break Down

CardDeckr is built on a modern stack: Astro frontend, Node.js backend, PostgreSQL database with 66 tables, and Stripe for payments. All tests run on Vitest, a fast test runner designed for modern JavaScript applications.

Here is the rough breakdown of the test suite:

Unit tests: ~4,500 tests covering business logic, utilities, validation rules, and UI components
Integration tests: ~2,200 tests covering API endpoints, database operations, and third-party integrations
End-to-end tests: ~200 tests covering critical user flows

Total: 6,900+ tests that run on every pull request before code merges to production.

The suite runs in under 3 minutes on our CI pipeline. That speed is critical. Slow tests mean developers skip them, and skipped tests mean bugs ship to production.

Testing Stripe Webhooks and Subscription Lifecycle

One of the most complex areas of any e-commerce platform is payment lifecycle management. Stripe sends webhooks for dozens of events: successful payments, failed payments, subscription renewals, subscription cancellations, refunds, disputes.

Each webhook must trigger the correct action in your platform. A failed payment webhook should downgrade the user’s access. A successful renewal should extend their subscription. A dispute should flag the order for review.

What happens when webhook handlers are not tested:

A customer cancels their subscription, but Stripe’s customer.subscription.deleted webhook fails silently. The customer still has access. You are providing free service.
A payment succeeds, but your handler does not update the order status. The customer paid, but their order is stuck in “pending.” Your support team spends hours manually fixing it.
A refund is issued, but your inventory does not get re-credited. You think you are out of stock when you are not. Lost sales.

CardDeckr’s webhook tests simulate every Stripe event type and verify the correct database changes occur. We use Stripe’s test mode and webhook fixtures to ensure our handlers are bulletproof before they see production traffic.

Database Integrity Tests Across 66 Tables

CardDeckr’s database has 66 tables covering users, orders, products, inventory, manufacturers, designers, payments, subscriptions, analytics, and more. Relational integrity matters. If a foreign key constraint breaks, or a cascade delete is misconfigured, data corruption follows.

Our database tests verify:

Foreign key constraints: Deleting a user cascades correctly to their orders, but not to shared data (e.g., product reviews)
Unique constraints: No duplicate email addresses, no duplicate SKU codes
Check constraints: Prices cannot be negative, order quantities must be positive integers
Index coverage: Queries that power the homepage, search, and admin dashboards hit indexes, not table scans
Migration rollback safety: Every schema migration can be rolled back without data loss

We run these tests against a real PostgreSQL instance (not SQLite mocks) to ensure behaviour matches production exactly.

How Comprehensive Tests Enable Confident Deployments

Here is the real business value of 6,900+ tests: confidence to deploy.

Without comprehensive tests, every deployment is a gamble. You merge code, cross your fingers, and hope nothing breaks. If something does break, you scramble to debug production, roll back the deploy, or issue a hotfix under pressure.

With comprehensive tests, deployments are boring. Code that passes the test suite ships to production safely. If tests fail, the deploy is blocked automatically. No broken checkouts. No silent payment failures. No 2am pages because inventory sync died.

CardDeckr’s deployment pipeline:

Developer writes code and tests locally
Pull request triggers CI: 6,900 tests run in ~3 minutes
Code review happens while tests run
Tests pass → code merges automatically
Production deploy happens via Cloudflare Workers (instant, zero-downtime)

We deploy to production multiple times per day because the test suite gives us confidence that nothing critical will break. That velocity would be impossible without automated testing.

The Business Case for Investing in Test Coverage

Writing 6,900 tests is not free. It takes time. It requires discipline. It slows down initial feature development slightly (though not as much as you think).

But the ROI is undeniable:

Fewer production bugs: CardDeckr has had zero payment processing bugs since launch. Zero inventory sync failures. Zero critical outages caused by bad deploys. The cost of those bugs in lost revenue, customer trust, and emergency fixes would dwarf the cost of writing tests.

Faster feature development: Once you have comprehensive test coverage, adding new features becomes faster, not slower. You can refactor aggressively, knowing tests will catch breakage. You can ship confidently without manual QA cycles.

Easier onboarding: New developers can contribute to CardDeckr within days because the test suite acts as executable documentation. Want to understand how pricing works? Read the unit tests. Want to see how checkout flows work? Read the integration tests.

Lower support burden: Bugs that never ship to production never generate support tickets. CardDeckr’s support volume is a fraction of what it would be without testing. That saves time and money every week.

If you are building custom SaaS software or an e-commerce platform, the question is not “Can we afford to write tests?” The question is “Can we afford not to?”

When to Invest in Test Coverage (and When to Skip It)

Not every project needs 6,900 tests. Here is when to invest heavily in testing:

You need comprehensive tests if:

You are building a platform where money changes hands (e-commerce, SaaS subscriptions, marketplaces)
You have complex business logic with multiple edge cases (pricing rules, inventory sync, multi-tenant access control)
You are integrating with third-party services that send webhooks or async events (Stripe, payment gateways, shipping APIs)
You plan to deploy frequently and iterate fast
You have multiple developers working on the same codebase

You can get away with lighter testing if:

You are building a marketing website with no payment flows
Your project is a short-lived prototype or proof of concept
You have a single critical path (e.g., a landing page with one contact form)
You deploy infrequently and manually QA every change

Fernside Studio builds fast, static marketing sites for SMBs with minimal testing (form validation, build-time checks, accessibility audits). We build e-commerce platforms and SaaS tools with comprehensive test suites like CardDeckr’s. Different projects need different approaches.

What Good Testing Looks Like in Practice

If you are commissioning custom software, here is what to ask your development partner:

“What test coverage do you maintain?” Look for >80% coverage on critical business logic, not 100% coverage on trivial code.
“How do you test payment flows?” They should mention Stripe test mode, webhook fixtures, and mocked payment intents.
“Do tests run automatically on every deploy?” If tests are manual or optional, they will be skipped under deadline pressure.
“How long does your test suite take to run?” Anything over 10 minutes is too slow and will be skipped by developers.
“Can I see a sample test for a critical flow?” Good tests are readable, focused, and clearly document expected behaviour.

At Fernside Studio, testing is non-negotiable for e-commerce and SaaS projects. We write tests as we build features, not as an afterthought. We run tests on every pull request. We deploy only when tests pass.

CardDeckr’s 6,900+ test suite is not a vanity metric. It is the reason the platform can process thousands of orders without manual intervention, deploy multiple times per week without outages, and scale confidently as the business grows.

If you are building a platform where reliability matters, where bugs cost money, customers, or trust, invest in comprehensive testing from day one. The upfront cost is real. The long-term savings are greater.

Ready to Build a Reliable E-commerce Platform?

Fernside Studio builds custom e-commerce platforms and SaaS tools with testing, reliability, and deployment confidence built in from day one. If you are planning a project where money changes hands and bugs are not an option, get in touch and we will scope it properly.

Or explore the full CardDeckr case study to see how we built a two-sided marketplace with 6,900+ tests, 66 database tables, and zero payment processing bugs since launch.