If you have ever tried to write a Playwright script against a Wix Stores site, you already know the pain: the DOM is a nest of auto-generated class names, everything is wrapped in iframes and data-hook attributes that shift between publishes, and a single theme tweak in the Wix editor can break every selector you own. This guide shows you how to test a Wix store using plain English instead, where an AI agent drives a real Chrome browser through your product-to-cart flow by intent, not by brittle CSS. You describe what a shopper does, the agent figures out where to click, and you get a deterministic pass or fail back.
The tool is BrowserBash, a free and open-source natural-language browser automation CLI. It is built for exactly this class of problem: sites where the markup is hostile to selectors but the user journey is simple to describe. A Wix store is the poster child. Let me walk you through why Wix breaks traditional automation, how an intent-driven approach handles it, and how to build a suite you can actually maintain.
Why testing a Wix store the traditional way hurts
Wix generates its front end. When you drag a Product Gallery widget into the editor and hit publish, Wix compiles that into React components with class names like _pinnedContainer_abc12 and data hooks like data-hook="product-item-name". Those hooks are more stable than the class names, but they are not a contract. Wix ships changes to its own component library, and your "Add to Cart" button can move from a <button> to an <a role="button"> inside a shadow-ish wrapper between one release and the next.
Then there are the structural problems that make Wix specifically painful:
- Iframes everywhere. The cart, some payment widgets, and third-party apps from the Wix App Market often render in nested iframes. Traditional scripts need explicit frame-switching logic, and if the frame loads late, your locator resolves against the wrong document.
- Lazy hydration. Wix sites are heavy. Product grids hydrate after the initial paint, so a naive
click()fires before the button is interactive and silently no-ops. - Locale and currency injection. Wix rewrites prices, button labels, and even URLs based on the visitor's region. A selector pinned to the text "Add to Cart" fails the moment your test runs from a different geo.
- Editor-driven churn. The people editing a Wix store are usually marketers, not engineers. They rearrange sections weekly. Every rearrange is a chance to break a selector-based test that nobody on the marketing side knows exists.
The result is a test suite that spends more time being repaired than it spends catching bugs. That is the exact failure mode intent-based automation is designed to avoid.
The plain-English approach: describe the shopper, not the DOM
With BrowserBash you do not write selectors. You write an objective, a short description of what a real shopper is trying to accomplish, and an AI agent drives Chrome step by step to make it happen. The agent takes a snapshot of the page, decides which element matches your intent, clicks it, and moves on. When Wix renames a class or moves a button, your objective still reads the same, because "add the first product to the cart" is true whether the button is a <button> or an <a>.
Install it once and you are ready:
npm install -g browserbash-cli
browserbash run "Open my Wix store at https://your-store.wixsite.com/shop, click the first product, choose a size if asked, and add it to the cart. Confirm the cart badge shows 1 item." --agent
That single command opens a real browser, navigates, reasons about the product grid, handles the size selector if the product has variants, adds to cart, and then verifies the cart count. The --agent flag emits NDJSON so you can pipe the result into CI or an AI coding agent. You get one JSON event per step and a final verdict with an exit code: 0 for passed, 1 for failed, 2 for an error, 3 for a timeout.
The important shift here is that you are testing behavior, not structure. A shopper does not care that the button is inside an iframe. They care that clicking it puts a product in the cart. Your test now cares about the same thing.
What "by intent" actually means on a Wix page
When the agent receives "click the first product," it does not grep the HTML for a class. It looks at the rendered accessibility tree and visible layout, identifies the leftmost product card in the gallery, and clicks the region a human would click. This is why it survives Wix's dynamic DOM: the agent is reasoning about the page the way a person looking at the screen would, so an internal class rename is invisible to it. That said, be honest with yourself about the tradeoff. Intent resolution costs a model call, and on a genuinely ambiguous page ("the button" when there are six buttons) the agent can pick the wrong one. Good objectives are specific: name the product, name the variant, name the expected outcome.
Building your first Wix cart test as a committable file
One-off run commands are great for exploration. For a suite you commit to your repo, use a Markdown test file. These are plain *_test.md files with a title, numbered steps, and support for variables and imports. They read like a manual test case, which means a QA lead or even the marketer editing the store can understand them.
Here is a wix_cart_test.md for a product-to-cart flow:
# Wix store: add a product to cart
1. Open https://your-store.wixsite.com/shop
2. Click the product named "Classic Cotton Tee"
3. Select size "Medium" if a size option is shown
4. Set the quantity to 2
5. Click the Add to Cart button
6. Open the cart
Verify: text "Classic Cotton Tee" visible
Verify: text "2" visible
Verify: 'Checkout' button visible
Run it:
browserbash testmd run ./wix_cart_test.md --agent
Notice the three Verify: lines at the end. Those are not agent-judged prose. In BrowserBash a Verify step that matches the assertion grammar compiles to a real Playwright check with no LLM judgment involved. "text visible," "'name' button visible," and stored-value equality all become deterministic assertions. A pass means the condition genuinely held on the page; a fail comes back with expected-versus-actual evidence in the run_end.assertions block and in the human-readable Result.md written after every run. That is the piece that makes an intent-driven test trustworthy: the navigation is flexible, but the checks are exact.
If you write a Verify line that falls outside the grammar, it still runs, but the agent judges it and flags the result with judged: true so you can tell the deterministic checks apart from the fuzzy ones. For a checkout flow you want as many of your assertions as possible to be the deterministic kind.
Seeding data and checking it: testmd v2 for hybrid flows
Wix Stores exposes REST APIs and, if you run a headless Wix or a custom backend, you often want to seed a known product state before you test the UI. BrowserBash has a version 2 test format for exactly this hybrid API-plus-UI case. Add version: 2 to the frontmatter and your steps execute one at a time against a single browser session. You get two deterministic step types that never call a model: API steps for seeding, and Verify steps for checking.
---
version: 2
---
# Seed an order then verify it in the account area
GET https://your-store.wixsite.com/_api/wix-ecommerce/cart
Expect status 200, store $.cart.lineItems[0].productName as 'seededProduct'
1. Open https://your-store.wixsite.com/account/my-orders
2. Log in with the test account
Verify: text stored 'seededProduct' visible
The API step runs a real HTTP request, asserts the status, and stashes a value from the JSON response into a variable. The plain-English steps in between run as a grouped agent block on the same page. The final Verify confirms the seeded product name actually shows up in the shopper-facing account view. One honest caveat: testmd v2 currently drives the builtin engine, which needs an ANTHROPIC_API_KEY or a compatible ANTHROPIC_BASE_URL gateway. It does not yet run on local Ollama or OpenRouter directly. If you are staying fully local and free, stick with v1 files and the default engine for now.
Handling the parts of Wix that fight back
No approach is magic. Here are the Wix-specific gotchas and how the plain-English model handles each one.
Variants, swatches, and required options
Many Wix products refuse to add to cart until you pick a variant. If you skip the size, the button stays disabled and a naive script clicks a dead element. Because the agent reads the page state, you can write the step defensively: "select size Medium if a size option is shown." The agent only acts when the option exists, so the same test works for products with and without variants. Be explicit about which variant, though. "Pick a size" leaves the agent to guess, and a guessed variant makes your assertions non-reproducible.
The cart iframe and the mini-cart
Wix often opens a slide-out mini-cart rather than a full page. Sometimes it is an iframe, sometimes an overlay. You do not need to know which. "Open the cart and confirm it lists the Classic Cotton Tee" describes the outcome, and the agent finds the cart UI wherever Wix put it. Your Verify: text "Classic Cotton Tee" visible then runs against whatever document the text lives in.
Prices and currency
If your store shows localized prices, do not assert on a hard-coded currency string. Assert on the product name and the quantity, which are stable across locales, and if you must check a price, store it from an API step and compare the number. Pinning a test to "$29.00" is how you get a red build every time someone runs it from a different region.
Lazy-loaded galleries
Because the agent snapshots the live page and waits for elements to be interactive before acting, the late hydration that breaks a fire-and-forget click() is handled for you. If a grid is genuinely slow, raise the timeout with --timeout 180 rather than adding sleeps.
Wix testing approaches compared
Here is an honest comparison of the realistic ways to test a Wix Stores checkout, so you can pick the right tool rather than the loudest one.
| Approach | Handles Wix's dynamic DOM | Maintenance when the store changes | Who can write it | Best for |
|---|---|---|---|---|
| Hand-written Playwright/Selenium | Only with careful data-hook selectors and frame handling | High: selectors break on editor changes | Engineers | Teams that already own a Playwright suite and want full control |
| Record-and-playback (traditional) | Poorly: records raw selectors | High: re-record on most changes | Anyone, initially | Quick smoke checks with a short shelf life |
| Manual QA | Yes, humans adapt | None, but does not scale | Anyone | Exploratory testing and edge cases a script cannot judge |
| Plain-English intent (BrowserBash) | Yes: acts on the rendered page, not the markup | Low: objectives survive DOM churn | QA, engineers, marketers | Regression suites on churny sites like Wix |
The plain-English row is not universally best. If your Wix store almost never changes and you already have a rock-solid Playwright suite with stable data-hook selectors, migrating buys you little. And for pure exploratory testing, a human still beats any agent. Where intent-based automation wins decisively is the churny regression suite: the flows that must keep passing while marketing rearranges the store weekly.
If you have an existing Playwright suite you do not want to throw away, you do not have to. BrowserBash can convert your specs to plain-English test files heuristically and deterministically, with no model involved:
browserbash import ./e2e/wix-checkout.spec.ts
It translates goto, click, fill, press, check, selectOption, getBy* locators, and common expect calls, turns process.env.X into {{X}} variables, and drops anything it cannot translate into an IMPORT-REPORT.md instead of inventing a step. You get a running start on your plain-English suite from the tests you already wrote.
Running the whole store suite in CI
Once you have a folder of Wix test files (add to cart, apply a coupon, guest checkout, account login), run them as a parallel suite. The orchestrator sizes its own concurrency from your real CPU and RAM, orders previously-failed and slowest tests first, and flags flaky ones.
browserbash run-all ./wix-tests --junit out/junit.xml --shard 1/2 --budget-usd 2.00
That runs a deterministic half of the suite (the --shard 1/2 slice is computed on sorted discovery order, so a second CI machine running --shard 2/2 covers the rest with no coordination), writes JUnit for your CI dashboard, and hard-stops spending once the suite crosses two dollars. Remaining tests report skipped, the suite exits 2, and the spend lands in RunAll-Result.md. For a Wix store where most flows are cache-warm, the actual cost is usually far under that ceiling.
BrowserBash also ships an official GitHub Action that installs the CLI, runs your suite, uploads the JUnit and NDJSON artifacts, supports shard matrix jobs, and posts a self-updating PR comment with the verdict table. Wire it into the workflow that runs when someone touches your storefront config, and every change gets checked before it reaches shoppers. The full setup lives in the GitHub Action docs.
Keeping the store green between deploys
A Wix store is a living site. Prices change, apps get added, someone accidentally unpublishes a page. Monitor mode runs a test on an interval and alerts only when the pass/fail state flips, in either direction, so you are not spammed on every green run.
browserbash monitor ./wix-tests/add-to-cart_test.md --every 15m --notify https://hooks.slack.com/services/XXX/YYY/ZZZ
Point it at a Slack incoming webhook and you get Slack-formatted alerts the moment your add-to-cart flow breaks, and a second alert when it recovers. Because the replay cache lets a repeat run replay recorded actions with zero model calls, an always-on monitor on a stable flow is nearly token-free. The agent only steps back in when the page actually changed, which on a Wix store is your early warning that something in the storefront moved.
Staying local, free, and private
If you are testing an unreleased store or you simply do not want product data leaving your machine, BrowserBash defaults to local models via Ollama. No API keys, nothing leaves your laptop. The model resolution order is Ollama first, then ANTHROPIC_API_KEY, then OPENAI_API_KEY, then OpenRouter, so if you have nothing configured it tries your local models first.
One honest note on model size: very small local models, roughly 8B parameters and under, get flaky on long multi-step objectives like a full guest checkout. The sweet spot is a mid-size local model in the Qwen3 or Llama 3.3 70B class, or a capable hosted model for the hardest flows. A three-step add-to-cart check runs fine on a small model. A ten-step checkout with a coupon, an address form, and a payment iframe wants more reasoning headroom. Match the model to the flow and you keep both cost and flakiness down.
You can browse more end-to-end walkthroughs in the BrowserBash tutorials, and the learn hub covers the assertion grammar and testmd format in depth. Pricing for the optional hosted dashboard is on the pricing page; the CLI itself, the engines, the local dashboard, and monitor mode all stay free.
Wiring BrowserBash into your AI coding agent
If you build your store changes with an AI coding agent (Claude Code, Cursor, Windsurf, Codex, Zed), you can hand that agent BrowserBash as a validation tool over the Model Context Protocol. One line adds it:
claude mcp add browserbash -- browserbash mcp
Now your agent can call run_objective, run_test_file, or run_suite directly and read back the structured verdict: status, summary, final state, assertions, cost, and duration. When the agent edits your Wix integration code, it can validate the add-to-cart flow itself and see the real result. A failed test is a successful validation here, the tool call succeeds and the agent reads the verdict, so your coding agent learns whether its change actually worked in a real browser rather than guessing. This is what "the open-source validation layer for AI agents" means in practice.
FAQ
Can I test a Wix store without writing any code or selectors?
Yes. That is the whole point of the plain-English approach. You describe what a shopper does, such as opening the shop, clicking a product, and adding it to the cart, and an AI agent drives a real Chrome browser to carry it out. There are no CSS selectors, no XPath, and no page objects to maintain, so a marketer or QA analyst who understands the store can read and even write the tests.
How does plain-English automation survive Wix's auto-generated class names?
The agent acts on the rendered page rather than the raw markup. It reads the accessibility tree and visible layout, then clicks the element a human would click for a given intent, so an internal Wix class rename or a data-hook change is invisible to the test. Your objective, like "add the first product to the cart," stays true regardless of how Wix compiled the button. Your deterministic Verify assertions then confirm the outcome exactly.
Is BrowserBash really free for testing my Wix store?
The CLI is free and open source under Apache-2.0, and it defaults to local models through Ollama so you can run tests with no API keys and no data leaving your machine. The engines, the local dashboard, monitor mode, and the replay cache are all free. You only pay if you bring a hosted model key for hard flows or opt into the paid hosted retention dashboard, which is optional.
What is the difference between a Verify step and a plain-English step?
A plain-English step is an action the agent interprets and performs, like clicking a product or filling a form. A Verify step is a check, and when it matches the built-in assertion grammar it compiles to a real Playwright assertion with no model judgment, giving you a deterministic pass or fail with expected-versus-actual evidence. Verify lines outside the grammar still run but are agent-judged and flagged as judged, so you always know which of your checks are exact.
Ready to stop repairing selectors every time your Wix store changes? Install the CLI with npm install -g browserbash-cli and point your first plain-English objective at your shop. An account is optional, but if you want the hosted dashboard and cloud runs you can sign up here and be testing your product-to-cart flow in a few minutes.