The argument in one line.
A production-ready Playwright test automation template can be assembled from scratch in under an hour by pairing a human architect's structural judgment with two different AI coding assistants used for two different jobs — planning versus execution.
Read if. Skip if.
- You're a QA engineer or SDET who wants a reusable Playwright + TypeScript starter project instead of rebuilding boilerplate on every new job or contract.
- You're curious how to split AI-assisted coding work between a planning assistant (Copilot Chat) and an execution assistant (Claude Code) on the same real project.
- You're prepping for a technical or QA interview and want a model for pre-building a login-flow automation answer before you're ever asked for one.
- You're comparing automation testing tools or frameworks and want a practitioner's plain-English rundown of tradeoffs (Playwright vs. Selenium waits, SpecFlow/Cucumber's extra layer, cross-browser scope creep).
- You want a finished, downloadable template repo — this is a live working session with dead ends, typos, and real-time debugging, not a polished tutorial.
- You need coverage of browsers beyond Chromium, or mobile/cross-browser testing — the whole session deliberately stays Chromium-only while the framework is being built.
- You're looking for Selenium- or Cypress-specific instruction — the hands-on work is entirely Playwright; other tools only come up in comparison.
The full version, fast.
A veteran test automation architect, currently job-hunting, live-streams building a Playwright + TypeScript automation template from zero — boilerplate he'd rather not rebuild every time a new job starts. He uses GitHub Copilot Chat to plan the setup steps (npm init, tsconfig, Allure reporting, Pino logging) and Claude Code to execute folder structure, page objects, and a login test against a public demo site. He monkey-patches Playwright's fill() and click() methods so every automated action logs itself with masked passwords and a green on-screen flash, then clones the finished project into an interview-ready copy via find-and-replace. A long tangent tours his own tool-comparison site and a public practice site (CandyMapper) built specifically for stress-testing automation frameworks.
Chat with this breakdown — free.
Sign in and you get 23 free chat messages on us — ask for the hook, quote a framework, find the exact transcript moment, generate a markdown action plan. Bring your own key when you want unlimited.
Create a free account →Where the time goes.

01 · Cold open: today's challenge
Paul introduces himself as a test automation architect currently job-hunting, plugs his LinkedIn, and sets today's goal: build a reusable Playwright + TypeScript automation template that can log in and out of a public demo site — the single most common ask in automation interviews.

02 · Scaffolding via Copilot's plan
Follows a step list from GitHub Copilot Chat: creates the project folder, runs npm init, installs Playwright with TypeScript, and edits the generated tsconfig.json. Detours to find VS Code's auto-save setting.

03 · Allure reporting + logger, then hands off to Claude Code
Installs Allure as the test reporter and picks Pino as the logger. Switches to Claude Code and asks it to scaffold the folder structure — source, page objects, wrappers, and tests directories — approving each proposed edit and bash command.

04 · Config review and a CLAUDE.md naming-convention doc
Reviews the generated playwright.config.ts (headless:false, Chromium-only project, Allure reporter, video/screenshot/trace only on failure). Objects to vague locator names like 'username', writes a rules file for naming conventions, then discovers the standard convention is CLAUDE.md at the project root and renames it there.

05 · Building the login page object
Builds the LoginPage page object model — username field, password field, login button locators — against the automationintesting.online admin login demo, renaming ambiguous fields like 'username' to 'username_field' per the new rules file.

06 · Writing the test and getting a first pass
Writes login.spec.ts, wires npm scripts for Playwright and Allure, trims the browser matrix from Chromium/Firefox/WebKit down to Chromium-only, points the base URL at the target site, passes credentials via CLI flags, and adds slow-mo so the headed browser is actually visible on screen.

07 · A reusable prompt, and a live audience joins
Asks Copilot to generate a single reusable prompt that reproduces the whole template setup from scratch. A viewer, blackeyemoody, joins chat asking which AI he's using and whether he counts as 'a programmer' — leading into a detour on 25 years of automation-engineering experience vs. AI-assisted 'vibe coding', and the three-layer automation framework (test scripts, page objects, support utilities) versus the extra Gherkin layer SpecFlow/Cucumber frameworks add.

08 · Tool comparison tour and the CandyMapper challenge
Tours his own site cataloguing dozens of automation tools (AccelQ, BugBug, Functionize, Autonomiq, and more) alongside a personal feature checklist covering basic-vs-advanced OS/browser coverage and framework support. Then demos candymapper.com, a Halloween-themed site he built specifically to stress-test tools with a fixed 8-step challenge: a blocking modal, an off-screen dropdown option, a forced multi-second load delay, and deliberately bad color contrast for accessibility testing.

09 · The rest of the feature checklist
Continues through element types, identify-by attributes (id, name, data-qa), the four kinds of waits (hardcoded sleep, implicit, explicit, fluid), headless-vs-headed tradeoffs, smoke/sanity/regression test organization, flaky-test retries, and treating any tool that shows a plaintext password during recording as disqualified.

10 · Cloning the template and monkey-patching fill()
Copies the finished template into a fresh 'interview' folder and does a project-wide find-and-replace to rename it. Back in the code, monkey-patches Playwright's fill() method so every automated field entry logs a description of the action to the console, with password values masked.

11 · Extending click() and polishing the run
Applies the same monkey-patch treatment to click(), adds a brief green on-screen flash so a human watching a headed run can see exactly what's being clicked, and tries — without success — to get the AI to reliably center the popped-up browser window on the correct monitor from a screenshot of his desktop layout.

12 · Sign-off
Wraps the two-hour stream as his dog Willow interrupts wanting attention; thanks the handful of live viewers and signs off.
Lines worth screenshotting.
- A standard UI automation framework has three layers — test scripts, page objects, and support utilities — while Gherkin/SpecFlow frameworks add a fourth feature-file layer that costs more to build and maintain.
- Automation engineers who use GitHub for version control are, by that fact alone, developers — not a separate lesser category from software engineers.
- The single most common request in an automation interview is a basic login-and-logout flow, which makes it worth pre-building before you ever walk into the room.
- Password fields should never display their plaintext value during an automated test recording — treat any tool that shows the password as typed as a disqualifying red flag.
- Test suites should be organized into smoke (roughly the first 10% of the app), sanity (the next 20%), and regression (everything else that has passed before).
- Tests marked work-in-progress but still left running will read as real failures and cause false alarms — exclude WIP tests from the run entirely instead of ignoring their red X.
- Ballooning cross-browser coverage from Chrome-only to Chrome, Edge, Safari, and three versions back roughly triples the maintenance burden without a proportional gain in real coverage.
- Hard-coded sleep waits are the first thing an experienced automation architect looks for, and rejects, when reviewing someone else's test project.
- A CI/CD pipeline that automatically reruns a failed test once, and lets a pass on the second try stand, is correctly treating a transient glitch as noise rather than a real bug.
- Monkey-patching a library's built-in fill() and click() methods lets every test action self-document with a console log line, with zero changes required in any file that calls them.
- Custom data attributes like data-qa are worth requesting from developers because, unlike CSS classes or auto-generated IDs, teams tend to treat them as a stable contract they won't casually break.
- Don't automate a date-picker widget by clicking through its calendar UI — if the input field accepts typed text, just type the date directly instead.
- A transient on-screen "Toast" pop-up that vanishes in about five seconds can still be validated after the fact by capturing it into an array the moment it appears.
Build Your Test Framework Once, Reuse It Forever
A reusable Playwright test template comes from disciplined choices made once — page objects, config review, naming conventions, and tool-evaluation habits — not from any single clever line of code.
- Before writing any test code, ask an AI planning assistant to lay out the setup steps as a checklist — it surfaces decisions (JavaScript vs. TypeScript, which test-runner config) you'd otherwise make by accident.
- Turn on your editor's auto-save immediately when starting a new project; hunting for that setting mid-session wastes more time than the setting itself saves.
- Pick a structured logger (here, Pino) over ad hoc console.log calls from day one — retrofitting logging into an existing test suite is far more painful than starting with it.
- A second AI tool can be handed the mechanical work of generating folder structure and boilerplate while a first tool is used for higher-level planning — split the work by strength rather than using one tool for everything.
- Review AI-generated config files line by line instead of accepting them wholesale — this session's TypeScript config initially had settings the presenter didn't understand or want.
- Writing your naming and coding conventions into a project rules file (CLAUDE.md at the project root, for Claude Code) up front stops an AI assistant from repeating avoidable mistakes for the rest of the session.
- A page object model centralizes every selector for one screen in a single file, so the rest of the test suite never has to know how that screen is actually built.
- Vague locator names like 'username' should be renamed to something explicit like 'username_field' — small naming discipline early prevents ambiguity once the page object grows.
- Trim your browser matrix to a single browser while building the framework itself — chasing cross-browser parity before the core framework works just multiplies debugging surface for no benefit yet.
- Credentials belong in environment variables or CLI flags passed at run time, not hard-coded into the test file — worth the habit even in a demo project.
- If a headed test run isn't visibly appearing, add a slow-mo delay before assuming the automation itself is broken — sometimes the browser window is just opening and closing too fast to see.
- Once a framework works, ask the AI to reverse-engineer a single reusable prompt that reproduces the whole setup — that prompt becomes the reusable asset, not just the code.
- A standard UI automation framework has three layers (test scripts, page objects, support utilities); Gherkin/SpecFlow-style frameworks add a fourth feature-file layer that increases both data handling and maintenance overhead.
- Experience mostly changes what you know to ask an AI for and when to catch it missing something, not whether you use AI at all — a beginner and a 25-year veteran can both 'vibe code', but only one knows what's missing from the output.
- When comparing automation tools, run the same fixed benchmark task against each one so the comparison is apples-to-apples instead of anecdotal.
- A deliberately bad-contrast color scheme is a legitimate, low-cost way to build an internal test target for accessibility and color-blindness tooling.
- Build test targets with realistic annoyances on purpose — an off-screen dropdown option, a blocking modal, a forced load delay — because production apps have all three.
- Prefer developer-owned custom attributes (e.g. data-qa) for locating elements over CSS classes or generated IDs — teams are far less likely to casually change an attribute added specifically for testing.
- Never automate a date-picker widget by clicking through its calendar UI if the input field will accept a typed date string — it's slower and more brittle for no benefit.
- Know the difference between a hard-coded sleep, an implicit wait, an explicit wait, and a fluid wait before a technical interview — it's a common basic screening question.
- Treat any paid automation tool that displays a plaintext password while recording a script as disqualified — it's a fast, simple filter for weak tools.
- Clone a finished template into a project-specific copy via a single global find-and-replace of the template's name — faster than rebuilding structure by hand for every new context.
- Monkey-patching a library's core methods (Playwright's fill()) means every test file that calls it automatically gets the new logging behavior, with zero per-call changes required elsewhere in the suite.
- A brief visual flash on the element being clicked makes a headed test run far easier for a human to follow in real time, at negligible cost to add.
- Not every polish request is worth finishing live — the presenter tried and failed to get an AI to reliably center a browser window on a specific monitor, and moved on rather than burning more time on a cosmetic detail.
Terms worth knowing.
- Page Object Model (POM)
- A design pattern where every selector and interaction for one screen (e.g. a login form) lives in a single dedicated file, so test scripts never touch raw selectors directly.
- Monkey patch
- Modifying or extending a library's existing function at runtime (here, Playwright's fill() and click()) so every caller gets the new behavior automatically, without editing each call site.
- Headless
- Running a browser automation script without a visible browser window. Faster, but you can't watch what the script is actually doing as it runs.
- Allure report
- A test reporting tool that turns raw pass/fail results into a browsable HTML dashboard with history, trends, and screenshots attached to failures.
- SpecFlow / Gherkin
- A testing approach where test cases are written as plain-English 'Given/When/Then' feature files, which then call automation code underneath — adding a translation layer on top of a standard framework.
- Flaky test / retry
- A test that fails intermittently for reasons unrelated to a real bug (network blips, timing). CI pipelines commonly rerun a failed test once before treating the failure as genuine.
- Trace (Playwright)
- A recorded timeline of a test run — DOM snapshots, network calls, console logs — that can be replayed step by step to debug a failure after the fact.
- data-qa attribute
- A custom HTML attribute developers add solely so automated tests have a stable way to find an element, independent of CSS classes or IDs that change for styling reasons.
- Smoke / sanity / regression testing
- Three tiers of test coverage run in increasing depth: smoke checks the most critical ~10% of the app works at all, sanity checks the next layer, and regression re-runs everything that has passed before.
- Implicit / explicit / fluid wait
- Three strategies for telling automated code to pause for an element to appear: implicit sets one global timeout for everything, explicit waits for one specific condition, and fluid polls repeatedly with custom timing and ignored exceptions.
Things they pointed at.
Lines you could clip.
“The most common thing somebody wants you to do is log in somewhere... I can definitely put together an automation framework that would type in Admin and the super secret password.”
“We are all programmers. We're all developers. If you're using GitHub and I'm using GitHub and you're a developer and I'm a software test automation engineer, we're still developers.”
“This site is intentionally in bad colors... if you have a tool that is able to go and analyze your website to see if it is following the rules for accessibility, you can test it against this site.”
“If you don't know those three [waits] and you're on an interview, they probably will not hire you.”
“If I'm paying for this, I should not see my password when I am recording the script... that used to be one of my — and it still is one of my — litmus tests for an automation tool.”
Word for word.
Don't just watch it. Burn it in.
See every word as it's spoken — crank it to 2× and still catch all of it. The same dual-channel trick behind Amazon's Kindle + Audible.
Named ideas worth stealing.
Three-Layer Automation Framework
- Test scripts
- Page Object Models
- Support/utility functions
A standard UI automation framework separates what a test does (scripts), how it finds and interacts with the page (page objects), and how it handles edge-case quirks like a field that silently rejects input (support utilities). Gherkin/SpecFlow-style frameworks add a fourth feature-file layer on top, which increases both data handling and maintenance cost.
Automation Framework Feature Checklist
- OS/Browser coverage
- Framework support (React, .NET, Vue, Angular)
- Basic actions (click, select, hover, upload)
- Element identification (id, name, data-qa)
- Wait strategies
- Reporting & CI/CD integration
- Security (masked passwords)
The personal checklist Paul uses to evaluate any automation tool before adopting it, split into basic and advanced tiers for each category.
CandyMapper 8-Step Challenge
- Navigate to the site
- Close the blocking modal
- Enter a name
- Click submit
- See the email-required validation
- Enter a valid-format email
- Click submit again
- Verify the confirmation message
A fixed, repeatable 8-step benchmark task Paul runs against every automation tool he evaluates, deliberately including an off-screen dropdown option, a forced load delay, and low-contrast colors as edge cases.
Selenium's Four Wait Types
- Hard-coded sleep
- Implicit wait
- Explicit wait
- Fluid wait
The four ways automated code can pause for an element to become ready, in increasing order of sophistication. Paul treats not knowing these as an automatic red flag in a technical interview.
How they asked for the click.
“I am looking for my new job. And, uh, if you are happen to be hiring... please, uh, consider looking for me.”
Delivered as a casual personal aside at the very top of the stream and referenced lightly again near the end — not a hard sell, no paid product or link-in-bio push, just a job-search plug woven into the technical content.





































































