Season Trailer & Orientation
Meet our local practice shop, understand actions and assertions, preview five browser-testing missions, and write two clear test expectations.
The Shop Is Online. The Cart Is Stuck.
The Shop Is Online. The Cart Is Stuck.
Our shop loads. Product cards appear. The server responds successfully. But when we press Add to Cart, the cart still shows 0.
Imagine this happening during a busy sale. This is an illustrative scenario, not a reported incident. Customers cannot complete the journey even though a server health check passes.
A server check answers, “Can this service respond?” It does not necessarily answer, “Can someone add a product and complete checkout?” Those are different questions.
That gap is our starting point in Playwright: Our First Browser Testing Mission, from MetaWise India.
Across five practical episodes, we will build a small browser-test suite around a local practice shop. We will catch a deliberate bug, improve our tests, investigate failures, and arrange for checks to run automatically when code changes.
Our mission: turn an expected customer journey into repeatable checks with visible evidence. No installation is needed for this orientation.
From Clicking to Checking
From Clicking to Checking
Think of a restaurant inspection. Checking that the kitchen has electricity does not establish that an order reaches the right table. We also need to follow the journey from order to delivery.
Browser testing follows a similar idea: we exercise a chosen journey through the page and check its result.
Playwright can control Chromium, Firefox, and WebKit browser engines. In this season, we use Playwright Test, which also provides a test runner, assertions, and debugging tools. We begin with Chromium to keep the first setup focused.
A script gives the browser instructions. The browser opens our shop and interacts with it. An assertion checks whether the observed result matches our expectation.
| Part | In our shop | What it tells us |
|---|---|---|
| Starting state | Cart contains no items | We know where the test begins |
| Action | Click Add to Cart once | We attempted the interaction |
| Assertion | Check that the cart count becomes 1 | We have evidence for the expected result |
A click is an action. A changed cart is evidence. The shared diagram that follows shows this path: test → browser → assertion.
An automated browser does not reproduce every human experience. Passing tests support the specific journeys, data, and browser configurations we checked. They do not establish that every feature works, or replace unit tests, API tests, accessibility checks, and human exploration.
action-to-evidence
action-to-evidence
What We Will Be Able to Do
What We Will Be Able to Do
We will work with a local practice shop and a simulated checkout. No real payment or customer data is needed. Deliberate bugs give us a safe place to investigate mistakes.
| Starting point | Useful progress we can demonstrate |
|---|---|
| Students and beginners | Explain an action and assertion, run a browser test, and describe a failure in a portfolio walkthrough |
| Developers adding UI tests | Choose clearer locators, check checkout boundaries, and keep tests independent |
| Engineers working with teams | Inspect failure evidence and introduce automated checks on code changes |
By the end, our deliverable is a small test suite with readable expectations, a debugging workflow, and a GitHub Actions workflow. This is a foundation we can explain and extend. Applying it to a production system also requires its own data strategy, security controls, coverage decisions, and maintenance.
Working with AI-generated tests
AI can suggest a test quickly. It can also choose a fragile selector or check the wrong result. We remain responsible for the evidence.
The engineer is the ringmaster: we direct the work and inspect its behavior. Whenever generated code looks convincing, we ask: What requirement does this check, and would it catch the bug we care about?
No paid AI assistant or API key is required. We can complete every exercise by writing and running the tests ourselves.
Five Missions, One Growing Test Suite
Five Missions, One Growing Test Suite
We start with one broken interaction and progressively build the habits needed to investigate and maintain browser tests. The shared roadmap that follows summarizes this sequence.
| Episode | Mission | Evidence of progress |
|---|---|---|
| 01 · The Crime Scene & First Blood | Start our local shop, install the lab dependencies, and check Add to Cart | An assertion exposes the deliberate cart bug; we inspect its failure and verify the fix |
| 02 · Ghost Clicks & Resilient Locators | Find controls by their role or label and understand automatic waiting | We replace a fragile locator and explain what the test waits for |
| 03 · Breaking Checkout: The Edge Case Gauntlet | Check quantities, invalid input, checkout rules, and independent starting states | Tests express boundary behavior and avoid depending on another test's changes |
| 04 · The Autopsy: Trace Viewer & Flaky Tests | Investigate failures using UI Mode and recorded traces | We use available page snapshots, action details, and network evidence to explain a failure |
| 05 · The Automated Shield: GitHub Actions CI | Run our suite on selected pushes and pull requests and retain reports | A workflow makes test results available alongside a code change |
A locator describes how a test finds a page element. A flaky test passes and fails without a relevant code change. Continuous integration (CI) runs automated checks as code changes are integrated. We will unpack these terms in their missions.
Before Episode 1
We need basic JavaScript familiarity: variables, functions, and reading a short code example. Prior testing experience is not required. We will explain the asynchronous test syntax as it appears.
- A computer with a supported operating system; a phone alone is not enough for this lab.
- Node.js 24 LTS as our recommended runtime, npm, a text editor such as VS Code, and a terminal.
- Internet access for the initial package and browser downloads; the shop and tests run locally afterward.
- Git and a free GitHub account for the hosted workflow in Episode 5. No account is needed for this orientation.
Current Playwright documentation lists Node.js 22.x, 24.x, or 26.x; Windows 11+, Windows Server 2019+ or WSL; macOS 14+; and supported Debian/Ubuntu releases. Before installation, we check the official system requirements against our machine and the lab version.
Free tools and episode access
The core lab uses free tools and needs no paid API key, cloud subscription, or real payment setup. Local test runs remain available throughout the season.
For hosted CI, our free practice route uses a public practice repository and standard GitHub-hosted runners. Private repositories have plan-dependent allowances; we follow the GitHub Actions usage guidance and keep reports within included storage limits. GitHub Actions is a hosted service, separate from the open-source local tools.
Access to seasons, episodes, and curated downloads follows the applicable MetaWise India membership tier. Free practice tooling and episode access are separate.
season-mission-roadmap
season-mission-roadmap
Our First Test Starts with a Sentence
Our First Test Starts with a Sentence
Before opening a terminal, let's write one expectation precisely.
Starting state: our cart is empty and a product is available. Action: we click Add to Cart once. Expected evidence: the cart count becomes 1.
That sentence is a tiny test specification: a starting state, an action, and an observable result. The image earlier showed the same relationship between our script, browser, and assertion.
A 60-Second Challenge
Let's write two more expectations for our practice shop using this pattern:
Given a known starting state, when an action happens, we expect an observable result.
We can choose a quantity change or an incomplete checkout form. First state the rule we intend to check: for example, quantity 2 at a fixed unit price should produce twice that price before any separate fees. We should not assume behavior such as a red border or a disabled button unless the shop requires it.
Our self-check: could another engineer tell whether each expectation passed without guessing? “Checkout works” is too vague. A named result gives us something we can inspect.
No submission or code is required. A note with two clear expectations is our outcome for this orientation.
In Episode 1, we start the local shop and turn the empty-cart expectation into a browser test. The first failure will give us evidence to investigate together.
Keep Learning, Keep Growing.