Visual testing for ecommerce
Ecommerce has the worst combination for visual defects — constantly changing catalogue data, third-party scripts, promotional overlays, and a checkout where a broken layout is lost revenue the same day.
Ecommerce combines every condition that makes visual defects likely with the shortest possible path from defect to lost money. The catalogue changes hourly, half the page is rendered by third parties, promotional overlays appear on a marketing schedule nobody tells engineering about, and the checkout is one funnel where a broken layout stops revenue the same afternoon.
Why storefronts break more than most applications
- Catalogue data is not test data. A product title that is 8 characters today is 94 tomorrow. A merchandiser uploads a portrait image into a grid designed for landscape. Neither is a code change, and neither shows up in review.
- Third-party scripts own your layout. Reviews widgets, chat, consent banners, recommendation carousels, payment buttons — all update themselves on their own schedule, and any of them can cover your add-to-cart button.
- Promotions ship as content. A banner added through the CMS pushes the fold down on mobile. No pull request, no review, no test.
- Price and badge variability. "$9" and "$1,299.00 was $1,899.00" occupy very different space in the same slot.
- Out-of-stock and edge states. The variant picker with one option left, the sold-out overlay, the back-order message — all rarely previewed and frequently broken.
What to cover, in order
| Priority | Page or state | Why |
|---|---|---|
| 1 | Checkout, every step | Shortest path from defect to lost revenue |
| 2 | Cart, including empty and single-item | Empty states are the most reliably broken screen in any product |
| 3 | Product detail — long title, many variants, out of stock | Where catalogue data breaks layout |
| 4 | Category and search results, including zero results | High traffic, and zero-results is rarely previewed |
| 5 | Paid landing pages | You are buying this traffic in real time |
| 6 | Homepage | Volume and brand impression |
Checkout first is not the obvious choice — it is the hardest to set up, because it is authenticated, stateful and full of payment integrations. It is still correct, because it is the only page where a defect costs money the same day. Getting a session and seeded data into a visual run is covered in visual testing authenticated pages.
The data problem, and how to actually solve it
A storefront rendering live catalogue data produces a different screenshot every run. Masking the product grid is tempting and defeats the purpose — the grid is precisely what breaks.
The approach that works is a fixture catalogue: a small set of products, fixed in your test environment, chosen to be deliberately awkward.
- A normal product. The control.
- A product with a very long title and a long description. Catches truncation and wrapping failures.
- A product with many variants — 12 sizes, 8 colours. Catches picker overflow.
- An out-of-stock product, and one with a single variant remaining.
- A product on sale, with a strikethrough price and a badge.
- A product with a portrait image where the grid expects landscape.
- A product with no image, because a merchandiser will eventually upload one without.
Seven products cover most of what real catalogue data does to a layout. This is more valuable than any tool decision on this page — with a fixture catalogue, ordinary visual testing works; without one, no tool will be stable.
Third-party scripts
The hardest part, because they change without you and they sit on top of your layout.
- Block them in the visual environment and test your own layout deterministically. Cleanest, and it means you are not testing whether their widget rendered.
- Or pin them and capture separately — a smaller nightly run with third parties enabled, so you find out when the consent banner update covers your buy button.
- Never mask the region they occupy. That is the region where your call to action lives; masking it means you have stopped testing the thing that matters.
Running both — deterministic on every pull request, third-party-enabled nightly — is the pattern that actually catches the consent-banner-covers-checkout class of defect without making every PR flaky.
Mobile first, genuinely
Most ecommerce traffic is mobile and most layout defects are mobile. If you can only afford one viewport, make it a phone, and make the first automated check a horizontal-overflow assertion — a storefront that scrolls sideways on a phone feels broken regardless of whether anything else is wrong. Responsive visual testing has the detail.
Platform notes
- Shopify and similar hosted platforms — theme updates and app installs change your storefront without a deploy. Run visual checks on a schedule as well as on changes, because there may be no change event to hang them from.
- Headless storefronts — you control the front end, so ordinary pull-request-triggered visual testing works normally. The catalogue data problem remains.
- Marketplace listings — largely outside your control; visual testing is not the tool.
That first point is worth sitting with. On a hosted platform, a large share of visual change arrives with no pull request attached, which means a purely PR-triggered strategy misses it entirely.
Frequently asked questions
What should ecommerce visual testing cover first?
Checkout, every step, including mobile. It is the hardest to set up because it is authenticated and stateful, and it is still first because it is the only place where a layout defect costs money the same day. Cart and empty-cart states come next, then product detail pages with awkward catalogue data.
How do you handle changing product data in visual tests?
Use a fixture catalogue of about seven deliberately awkward products in the test environment: a normal one, one with a very long title, one with many variants, one out of stock, one on sale with a badge, one with a portrait image in a landscape grid, and one with no image. Masking the product grid instead defeats the purpose, because the grid is what breaks.
How do you stop third-party scripts making ecommerce visual tests flaky?
Block them in the per-pull-request run so your own layout is tested deterministically, and run a smaller nightly pass with them enabled to catch the case where a consent banner or chat widget update covers your buy button. Do not mask the region they occupy — that is where your call to action lives.