Getting Your Playwright Framework Running: Your Starting Point for Phase 3

In the last post, I laid out what this series is: the record of scaling a working  Playwright and TypeScript test automation framework from one worker to enterprise-ready, bugs and fixes included. Before any of that architecture makes sense, you need the same starting point I had - the framework as it stood at the end of Phase 2, running cleanly on your machine.

That's this post. Short, practical, and the only one in this series that isn't about something breaking.

What you're cloning

The repository behind this series is the framework built step by step across Phase 1 and Phase 2 of my Playwright Automation Testing course:

Page Object Model, custom fixtures, API testing, CI/CD, AI-assisted review - tested throughout against qa-cart.com, a WooCommerce-based demo store I built specifically for this course. It's not a sanitised example app; it's an e-commerce flow - cart, coupons, checkout, order history, profile management - which is exactly why the scaling problems in this series turned out to be worth documenting. Toy apps don't leak cart state under concurrency. Working ones do.

If you want the full story of how this framework came together - the reasoning behind each design decision, narrated, with exercises - that's Phase 1 and Phase 2 of the course. This series picks up exactly where that leaves off.

One assumption before we start: this post assumes Git and GitHub are already set up on your machine. If they're not, the Git & GitHub setup lecture from the course is a free preview - no purchase needed. Get that sorted first, then come back here.

Clone with a clean history

Open terminal/command prompt

git clone https://github.com/anuradha-learn/playwright-phase2-framework.git playwright-phase3-enterprise-blog

cd playwright-phase3-enterprise-blog

// Remove Phase 2's history

rm -rf .git

//initialize repo

git init

git branch -M main

Windows note: the rm -rf .git line works as-is in Git Bash, which comes bundled with Git for Windows - that's what I'd recommend using. If you're in native PowerShell instead, swap that one line for:

Remove-Item -Recurse -Force .git

Everything else in this post - npm, npx, git - behaves identically across Git Bash, PowerShell, and Mac's terminal.

We start fresh history here rather than carrying over the full Phase 2 commit log, so this repo's history maps cleanly onto Phase 3, post by post, tag by tag - not tangled up with months of earlier iteration.

Open the project in VS Code

From here on, everything is easier done inside VS Code rather than jumping between a plain terminal and a text editor.

code .

This opens the cloned folder directly in VS Code - works the same on Mac and Windows, as long as VS Code's code command is installed. If it's not recognised, open VS Code manually and use File → Open Folder instead.

Check .gitignore, create .env

Both purely visual, right in the Explorer panel:

• Open .gitignore and confirm it lists:

.env
node_modules
auth/storage
test-results
playwright-report
allure-results
allure-report
blob-report
reports

• Right-click the project root → New File → name it .env - leave it empty for now, we'll fill it in shortly

Publish to GitHub, directly from VS Code

In your browser: go to GitHub → New repository → name it playwright-phase3-enterprise-blog → leave it empty, no README, no .gitignore, no license - you already have all of that from the clone.

Back in VS Code, in the integrated terminal (Ctrl+` if it's not still open) or from the View menu, open Terminal:

git remote add origin https://github.com/anuradha-learn/playwright-phase3-enterprise-blog.git
git add .
git commit -m "Initial commit: Phase 3 starting point, carried forward from Phase 2"
git push -u origin main

Check GitHub in your browser afterwards to confirm it landed - you should see the full framework there, freshly pushed, with a single initial commit.

Set up your .env

Your repository is live, but it's missing the one file that can never live inside it: .env is gitignored on purpose, so this step happens locally after the push every time you set up this project fresh.

Create your own qa-cart.com account. 

The login credentials in this series aren't something I can hand you directly - sharing my own account would mean every reader hitting the same login at once, which is precisely the shared-state problem this entire series exists to fix. Go to qa-cart.com/my-account/, use the registration form (email + password - username generates automatically), and create your own account. Update the dummy address too, so you have a complete checkout scenario ready for later posts.

At this stage, the framework is still exactly as it was at the end of Phase 2 - one shared login, not yet the identity pool this series builds toward. That pool (and the TEST_USER_1 through 4 naming that comes with it) shows up in a later post, once we've actually built the architecture for it. For now, the config validates a single account, so that's what goes in .env.

Here's a sample .env (created at the project root) to work from:

BASE_URL=https://qa-cart.com
WC_BASE_URL=https://qa-cart.com
API_BASE_URL=https://dummyjson.com
WC_CONSUMER_KEY=ck_c9aa6868338098568e7c8a3263e635e3123ae940
WC_CONSUMER_SECRET=cs_51bdd00527a5d9df49b323925f86c277948c411d
DEMO_USER=your-email@example.com
DEMO_PASS=your-chosen-password

WC_CONSUMER_KEY/WC_CONSUMER_SECRET are shared, scoped read-only keys for the WooCommerce API on qa-cart.com - safe to reuse across readers, since API access doesn't carry the same shared-session risk that a logged-in account does. DEMO_USER/DEMO_PASS are yours alone, from the account you just registered.

The readiness checklist

With .env in place, three things are left to confirm before building anything new on top of this. Run all of it from the VS Code integrated terminal.

Install dependencies. 

Two commands, not one: npm install gets the npm packages, but Playwright's actual browser binaries (Chromium, Firefox, WebKit) are a separate download - skip the second line and your first test run fails immediately on a fresh machine:

npm install
npx playwright install

If you've already got Playwright browsers cached on your machine from other projects, that second command can finish instantly with no visible output at all - no progress bar, no confirmation message, just your prompt returning. That's not a failure; Playwright checks what's already installed before downloading anything, and on a machine that already has the right versions cached, there's simply nothing left to do.

On a fresh machine, you'll see real download progress instead. Either way, npx playwright --version is the quick way to confirm everything actually landed - it should print back a version number, which is your signal that both the CLI and the browsers behind it are in place.

Verify the run with a single worker. 

This confirms the framework actually runs before you build anything new on top of it. Notice you don't need to run setup separately - the config already declares chromium as dependent on it, so Playwright runs authentication automatically before your tests:

npx playwright test tests/api --workers=1

If this doesn't pass cleanly, that's worth resolving now - every post from here forward assumes this baseline works.

Tag the starting point, from the same terminal, so this exact state of the code is always reachable, no matter how much changes later in the series:

git tag -a phase3-starting-point -m "Clean starting point for Phase 3: Enterprise Scalability"


git push origin phase3-starting-point

That's it. Framework running, published to GitHub, .env configured, starting point tagged - all from the VS Code terminal.

What's next

The next post picks up right where the AI Framework Review lesson in the course leaves off - a quick recap of the parallel-readiness concepts you've already seen there. Then we stop treating them as theory: we take this same framework, the one you just confirmed passes cleanly with a single worker, and run it against real parallel execution for the first time - and watch it break. Not from bad test code. From a single shared login trying to do a job it was never designed for.

That's the problem the rest of this series exists to solve.

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

Post 1 

Repo link 

Course link