Running in Parallel for the First Time -and Watching It Break

If you followed Post 2, you've got the framework running, .env configured, one worker, one clean pass. That's the baseline every post from here forward assumes.

This post is short, and it's the last one before the real architecture work starts. Before we design anything, it's worth actually watching the problem happen - not just being told about it.

A quick recap, not a re-teach

If you've been through the course, this will be familiar: the AI Framework Review lesson already walked through what "parallel-ready" means at a conceptual level, and the parallel execution lectures covered what a Playwright worker actually is - an independent process, capable of running test files concurrently instead of one after another.

If you haven't taken the course, here's the one-line version: a worker is a separate process Playwright spins up to run tests. One worker means everything runs sequentially, in order, one test finishing before the next starts. More than one worker means multiple tests run genuinely at the same time.

Right now, this framework runs with one. Let's change that.

Turning up the workers

The config you cloned in Post 2 doesn't hardcode a worker count outside CI - so this is just a CLI flag:

npx playwright test --workers=4

If you're running the same suite you verified in Post 2, expect something to go wrong. Not every test - some will pass fine, particularly anything that doesn't touch a logged-in session. But somewhere in the run, you'll likely see something like:

• A cart test asserting an item count that doesn't match what the test itself added

• A coupon test failing to find a discount that should be there - or finding one it never applied

• Session Expired

• A checkout test timing out on a step that passed perfectly a moment ago, run alone

None of these is bugs in the test code. Every one of them ran correctly, in isolation, in Post 2. The only thing that changed is how many of them are now running at once.

Why this happens

Look back at the .env you set up: one DEMO_USER, one DEMO_PASS. Every worker Playwright spins up authenticates as that same account, against the same live session, on the same qa-cart.com backend.

WooCommerce doesn't just track a cart in the browser - it ties cart and session state to the account, server-side. So when worker 1 adds a product to the cart at the same moment worker 2 applies a coupon and worker 3 starts checkout, they're not four independent tests running concurrently. They're four processes fighting over one shared piece of state, each one silently overwriting or interfering with what the others just did.

This is the actual reason "it worked with one worker, then I added three more" from the first post in this series wasn't a fluke or a flaky test. It's the predictable, guaranteed outcome of pointing concurrent workers at one identity.

Three separate problems, not one

It's tempting to lump this under "flaky tests" and move on. Worth being more precise than that, because what you just watched break is actually three distinct problems wearing one costume:

1. Identity isolation - one login, many workers, no separation between who each worker is acting as.

   
   

2. Shared resource isolation - coupons, stock levels, and other backend state that multiple workers can collide on even with different accounts.

   
   

3. Test data isolation - cart contents, order history, and other state that leaks between tests running sequentially on the same worker, not just across workers.

   
   

You've only demonstrated the first one so far. The other two are still ahead - they show up even after identity gets fixed, which is exactly why this can't be solved with one quick patch.

What's next

The next post is where the actual architecture begins: designing an identity pool that gives each worker its own account instead of one shared login - the fix for the specific failure you just watched happen. Everything from here builds directly on top of it.

This is Post 3 of the Phase 3: Enterprise Scalability series.

Post 1 · Post 2 · Repo link · Course link