Your First Playwright Test for WooCommerce

Performance Is Worthless If the Store Is Broken

You optimized your TTFB. You tuned Redis. Your Lighthouse score is green across the board.

Then a plugin update silently breaks the “Add to Cart” button. Nobody notices for three days — except your customers, who leave.

Performance tests answer one question: how fast? But there’s a more fundamental question they completely ignore: does it work at all?

That’s what Playwright answers. It launches a real browser, walks through your store like a customer would, and tells you — in seconds — whether the critical paths still function. Add to cart. Checkout. Payment. The flows that directly convert to revenue.

If you’re running a WooCommerce store and you’re not testing these flows automatically, you’re flying blind after every update.

Why This Matters for WooCommerce Specifically

WooCommerce is a plugin ecosystem stacked on top of WordPress. Every update — core, theme, or plugin — is a potential breaking change. And the failures are almost never loud. They’re silent:

• A gateway plugin update changes the checkout form markup. The page loads fine. The “Place Order” button does nothing.
• A theme update shifts a CSS class. Your cart popup stops appearing. The product page looks normal otherwise.
• A WooCommerce minor release changes how shipping methods render. No errors in the log. Customers just can’t select delivery.

You won’t catch these by looking at the admin dashboard. You won’t catch them with uptime monitoring. You catch them by simulating what a customer actually does — clicking through the store, adding products, and completing checkout.

That’s exactly what Playwright does.

Getting Started

Install Playwright

You need Node.js on your machine. Then:

npm init playwright@latest

Accept the defaults. You’ll get a tests/ directory and a playwright.config.ts file. That’s your entire setup.

Write Your First Test

Create tests/woo-add-to-cart.spec.ts:

import { test, expect } from "@playwright/test";

const STORE_URL = "https://yourstore.com"; // Your store URL

test("add product to cart and reach checkout", async ({ page }) => {
  // 1. Open a product page
  await page.goto(`${STORE_URL}/product/sample-product/`);

  // 2. Handle the cookie banner — adjust the selector to match your plugin.
  //    Rejecting cookies keeps the test fast (no tracking scripts loaded).
  await page.getByRole("button", { name: "Reject all" }).click();

  // 3. Find the "Add to Cart" button and verify it's visible.
  //    If it doesn't appear within 5 seconds, the test fails.
  const addToCartButton = page.locator('button[name="add-to-cart"]');
  await expect(addToCartButton).toBeVisible();
  await addToCartButton.click();

  // 4. WooCommerce shows a cart notification after adding a product.
  //    The exact markup depends on your theme — adjust the selector.
  const viewCartButton = page.locator("#cart-popup a.wc-forward").first();
  await expect(viewCartButton).toBeVisible();
  await viewCartButton.click();

  // 5. Verify the product is in the cart — exactly 1 item.
  await expect(page.locator(".cart_item")).toHaveCount(1);

  // 6. Verify the checkout button exists. If it's missing,
  //    something broke in the cart template.
  const checkoutButton = page.locator(".checkout-button");
  await expect(checkoutButton).toBeVisible();
});

Every line with await tells Playwright: finish this step before moving on. Every line with expect is an assertion — if it fails, the test stops and tells you exactly what went wrong.

Run It

npx playwright test

That’s it. Playwright opens a browser, runs the scenario, and reports the result.

Want to watch it happen in real time?

npx playwright test --headed

If the test fails, Playwright saves a screenshot and a trace file. Open the report to step through what happened:

npx playwright show-report

When to Run Tests

You don’t need to run tests after every CSS tweak. But there are moments where skipping them is reckless:

• WooCommerce core update — The most common source of silent checkout breakage. New versions can change cart structure, checkout fields, or how payment gateways hook in.
• Theme update — Themes control the layout and CSS selectors your tests rely on. A theme update that breaks a test might mean the store is broken — or it might mean you need to update a selector. Check manually first.
• Plugin install or update — Especially payment, shipping, and cart plugins. Plugin conflicts are WooCommerce’s greatest hit.
• Custom code changes — Custom WooCommerce code, template overrides, new hooks. Easy to break something without noticing.
• On a schedule — Even without changes on your end, external services (payment gateways, courier APIs) can go down. A daily or hourly test run gives you early warning before customers start complaining.

For automation, plug your tests into CI/CD (GitHub Actions works well) or schedule a cron job that runs npx playwright test at a set interval.

What to Test Next

One test is a good start. Here’s where to expand:

• Product search and filtering — Does the search actually return results? Do category filters work?
• Customer login and order history — Can returning customers access their accounts?
• Coupon codes — Does the discount apply correctly?
• Multiple payment methods — If you offer Stripe, PayPal, and bank transfer, test all three.
• Shipping method selection — Can customers choose between delivery options?

Visual Regression

Playwright can also catch things no functional test will — layout shifts, broken styling, elements that moved after an update:

await expect(page).toHaveScreenshot("checkout-page.png");

This compares a screenshot against a baseline. If anything changes visually, the test flags it. Useful after theme updates when the store “works” but looks wrong.

The Full Picture

Playwright tells you the store works. Constant performance engineering as part of WooCommerce Care tells you it stays fast. You need both.

A store that loads in 400ms but has a broken checkout is worse than a store that loads in 2 seconds and actually converts. Start with one test. Run it after every update. Expand from there.

If you don’t want to build and maintain test suites yourself — we offer Playwright testing for WooCommerce as a service. Tests built around your specific store, your plugins, your custom logic. Not generic scripts. Real coverage for the flows that make you money.