Can you automate testing on a Shopify store?

Yes. Theme Check lints Liquid and JSON in CI, Shopify CLI creates a preview theme per branch, Lighthouse CI enforces performance budgets, and Playwright or Cypress runs end-to-end journeys through cart and checkout against the preview theme using a test payment method. Visual regression tools catch layout changes the functional tests cannot describe.

How do you test Shopify checkout without placing real orders?

On a development store use Shopify’s Bogus Gateway, which accepts test card numbers and creates real-looking orders without charging. On a live store, run the journey on a staging setup with Shopify Payments in test mode, or stop the automated test at the payment step and verify the order creation separately. Never use real cards on production in automated runs.

What is Theme Check in Shopify?

Theme Check is Shopify’s linter for theme code. It scans Liquid and JSON templates for undefined objects, missing translations, deprecated filters, oversized assets, unused snippets and accessibility issues, and runs locally through Shopify CLI or in continuous integration. Failing Theme Check on every pull request is the cheapest quality gate a Shopify store can add.

How often should a Shopify store run regression tests?

On every code change before merge, immediately after publishing a theme as a smoke test, and on a daily schedule against a staging copy that has the same apps as production, because third-party app updates arrive without warning. Run the full suite before major campaigns such as Black Friday.

Do Shopify apps need their own tests?

Custom apps do: unit tests for business logic, webhook handling tests for retries and duplicate deliveries, and integration tests pinned to a Shopify API version with a quarterly run against the next version. Third-party apps cannot be tested directly, so cover them through the scheduled end-to-end journeys that exercise their storefront features.

Shopify Store Testing: Automated QA for Themes and Checkout

A manual checklist catches what a person remembers to click. It does not catch the variant picker that broke on the twelfth release, the checkout that fails only with a discount code and a non-US address, or the app update that doubled the cart script. This guide is about testing Shopify stores the way software teams test software: automatically, on every change, before customers see it. For the one-time pre-launch checklist, see our Shopify store testing checklist; for diagnosing a checkout that is already failing, Shopify checkout errors; for testing what converts rather than what works, Shopify A/B testing.

Shopify Store Testing: Automated QA for Themes, Checkout and Apps (2026)

Why Shopify stores need automated QA now

Three things changed. Stores release more often: a theme edit, an app install and a Shopify platform update can all land in the same week. Themes got more complex: Online Store 2.0 sections, theme blocks, metafield-driven templates and checkout extensions mean more code paths than any checklist covers. And the cost of a silent failure rose with ad spend: a broken add-to-cart on one variant type can run for days while the traffic keeps arriving. Automated tests are how you turn “we think it works” into “it worked at 09:14 on the preview theme, here is the report”.

The four layers of a Shopify test suite

1. Static checks: Theme Check and linting

Theme Check is Shopify’s own linter for Liquid and JSON. It flags undefined objects, missing translations, deprecated filters, oversized assets, unused snippets and accessibility problems in templates before anything renders. Run it locally through Shopify CLI and in continuous integration on every pull request; a theme that fails Theme Check does not get a preview. Add a JavaScript linter and a CSS linter for your own assets. This layer is cheap, fast and catches a surprising share of “it broke on one template” bugs.

2. Preview builds: every change gets its own theme

Shopify CLI pushes a branch to an unpublished theme and returns a preview URL. Wire that into CI so every pull request produces a preview theme with the branch name, and every test below runs against that preview, never against the live theme. Delete previews when branches merge; Shopify limits the number of themes per store, and stale previews are how limits get hit at the worst moment.

3. Performance budgets: Lighthouse CI

Run Lighthouse in CI against the preview theme for the homepage, a collection and a product page, with budgets: a mobile performance score floor, a maximum for total JavaScript, thresholds for Largest Contentful Paint and Cumulative Layout Shift. A pull request that pushes LCP over the budget fails, and the developer sees which asset did it before a merchant does. Field data in Search Console remains the truth for real users; Lighthouse CI is the early warning. Our Core Web Vitals guide covers what the numbers mean.

4. End-to-end tests: Playwright through checkout

This is the layer that catches revenue bugs. With Playwright (or Cypress), script the journeys that make money and run them against the preview theme on mobile and desktop viewports:

Search for a product, open it, select each variant option type, add to cart, confirm the cart drawer and cart page totals.
Apply a discount code; confirm the price change; remove it.
Proceed to checkout, fill contact and address for two or three markets, confirm shipping rates appear and the correct ones are selected by default.
Reach the payment step and complete the order with a test payment. On a development store use Shopify’s Bogus Gateway; on a live store use Shopify Payments test mode on a duplicate or staging setup, never real cards on production.
Confirm the order confirmation page, then confirm the order exists in admin via the Admin API.
Customer account: log in with new customer accounts (one-time code flow), view an order, update an address.

Keep the suite small and reliable: a dozen journeys that always pass are worth more than a hundred that fail randomly. Tag tests by template so a change to the product section runs the product journeys first.

Visual regression: the bug the tests cannot describe

Functional tests do not notice that the price now renders under the image or that the announcement bar covers the menu on small screens. Visual regression tools (Playwright’s screenshot comparison, Percy, Chromatic and similar) capture the key templates at several viewports and diff them against the last approved version. Review diffs in the pull request; approve intended changes, fix unintended ones. Set a small tolerance so anti-aliasing does not create noise, and mask dynamic areas such as recently viewed products.

Testing apps and integrations

Development stores. Build and test custom apps on a development store with realistic catalogue data, not on the live store.
Webhooks. Test that your app or integration handles orders/create, products/update and app/uninstalled with retries and idempotency; Shopify redelivers webhooks, and duplicate processing is a classic bug.
API versions. Pin an API version, and add a CI job that runs the integration tests against the next version each quarter before the old one retires.
Third-party app updates. You cannot control them, so run the end-to-end suite on a schedule (daily, and before campaigns) against a staging copy of the live theme with the same apps. When a review or upsell app ships a breaking change, the schedule catches it.
Checkout extensions. On Shopify Plus, checkout UI extensions and Functions get unit tests in their own repositories plus an end-to-end journey that exercises them in checkout.

Data checks after imports and migrations

After any bulk import or migration, automated counts beat spot checks: products, variants, images, collections, customers and orders compared between source and target; a sample of product pages fetched and checked for price, availability and image presence; every URL in the redirect map requested and asserted to return a 301 to a 200. Our migration team runs these as scripts before launch, and the same scripts become the regression suite afterwards.

Test data and environments

Automated tests are only as good as the store they run against. Keep a staging store or a duplicate theme that mirrors production: the same apps, the same theme settings, a copy of the real catalogue with a handful of “test-only” products that cover the awkward cases — a product with every option type, a product with one variant, a sold-out item, a pre-order, a product with a metafield-driven template, a gift card. Give the suite fixed customer accounts, fixed discount codes that never expire, and addresses in each market you sell to. Reset test orders on a schedule so reports stay readable. Never point automated runs that place orders at production with real payment methods; the Bogus Gateway on a development store and Shopify Payments test mode on staging exist for this.

A sample end-to-end journey, in plain words

The single most valuable test on most stores reads like this: open the preview theme on a mobile viewport; search for the test product; open it; choose the second size and the third colour; check that the price and image changed; add to cart; open the cart drawer and confirm quantity and total; apply the fixed discount code and confirm the new total; go to checkout; fill contact details, a UK address and a US address in two runs; confirm the expected shipping rate is preselected; pay with the test gateway; confirm the thank-you page shows the order number; query the Admin API and confirm the order exists with the right line items, discount and shipping. Ten minutes to write with a recording tool, two minutes to run, and it catches the bugs that reach revenue first.

A release process that uses all of this

Developer opens a pull request; CI runs Theme Check and linters.
CI pushes a preview theme and posts the URL.
Lighthouse CI runs budgets on the preview; end-to-end and visual tests run on mobile and desktop.
Failures block the merge; passing results are attached to the pull request for review.
A person does a short exploratory pass on the preview: the things that are new, not the things that are automated.
Merge; publish the theme during a quiet window; run a smoke subset of the end-to-end suite against production immediately after; keep the previous theme unpublished for rollback.
Monitoring watches checkout conversion and error rates for 24 hours; a drop triggers a rollback, not an investigation.

What to automate first if you have nothing

In order of value per hour: Theme Check in CI; one Playwright journey from product page to paid test order on mobile; Lighthouse CI on the product template; visual regression on the homepage and product template; the scheduled daily run against staging. That is a week of work for a developer who has done it before and it prevents the class of bugs that costs stores the most. If you want it set up and maintained rather than built from scratch, our Shopify theme development team ships this pipeline with every theme, and the tech audit starts by measuring what your current process misses.