11.18 — Capstone: the full test suite

The last checkpoint isn’t a lesson — it’s the first day of the job, rehearsed: a real repo, a real target app, and a complete suite assembled from everything you own. POM structure, bottled auth, tagged sets, a data table, one mocked sad path, two browser lanes, and CI publishing the report. Then the graduation stamp — and what to do with it.

watch it happen

// THE MISSION (a real repo, outside this app):
// target: the Phase 7 todo app + a demo shop
//
//  1  npm init playwright@latest        (11.2)
//  2  config: baseURL from env, retries (11.3)
//  3  pages/: TodoPage, CheckoutPage    (11.9)
//  4  fixtures: shopper via storageState(11.7/11)
//  5  specs: @smoke set + @regression   (11.13)
//  6  data-driven coupon table          (11.8)
//  7  one mocked sad path (500 banner)  (11.10)
//  8  projects: chromium + webkit       (11.12)
//  9  push → CI runs → report published (11.16)
// 10  a flake appears → clinic → fixed  (11.15)
//
// then: pin the repo. It IS your portfolio.

The mission, plainly: build a REAL suite in a REAL repo (outside this app) against two targets — the todo app you built in 7.9, and a public demo shop. Nothing new is taught below; every box on the board is a lesson number you’ve completed. This is assembly, and assembly is the job.

under the hood

The deeper story, with the real names for things — this part is what turns “I saw it” into “I can explain it.”

Suggested repo shape, so the blank page never wins: tests/smoke/, tests/regression/, pages/, fixtures.ts, .auth/ (gitignored), playwright.config.ts, .github/workflows/. Total scope that reads as professional: 20–30 tests. Small enough to polish, large enough to prove structure.

Public demo targets that welcome practice suites exist precisely for this (search “practice automation site” — several are maintained for testers). Your own 7.9 todo app is the better half of the capstone though: YOU know its spec, so your expected values are honest.

The README is worth an hour: what the suite covers, how to run it (three commands), the report link, one paragraph on structure decisions (why POM, why the mock/unmock split, how auth works), and the flake story. Interviewers read READMEs before code — it’s the teach-back principle (every lesson’s!) applied to your portfolio.

And the map from here: this course made you job-ready for E2E automation. The adjacent territories when you want them — deeper API testing, performance testing, containerized grids, other runners — are all built from concepts you now hold (HTTP, processes, CI, doubles). Nothing in this field will read as magic again. That was the whole point.

your turn

⌨️ the graduation run

One program, the whole course: a page object wrapping the app, a data table generating tagged tests, a grep’d smoke run, then the full suite with a counted summary and an exit code. Every line is a lesson you own.

requirements:

Keep the starter’s makeApp. Build class CheckoutPage (11.9): constructor stores a fresh app; applyCoupon(code) delegates; total() reads.
The table (11.8): cases = SAVE10 → 900 (this row’s name ends with @smoke), SAVE25 → 750, EXPIRED → 1000. Generate tests with makeTests(cases): each { name, run }, name = coupon CODE → TOTAL (+ the tag where the row has one), run = a fresh CheckoutPage, apply, strict-compare (10.3’s beats in one arrow).
The runner (10.5): runSuite(tests, grep) — filter by grep when given (11.13), print ✓ name per pass, count, and return the fail count.
The ceremony: print smoke run:, run with grep "@smoke"; print full run:, run all; print N passed, M failed — exit CODE from the counts (9.2, one last time); and if the exit code is 0, print 🎓 GRADUATE.

when you press RUN, the console must show exactly:

smoke run:

✓ coupon SAVE10 → 900 @smoke

full run:

✓ coupon SAVE10 → 900 @smoke

✓ coupon SAVE25 → 750

✓ coupon EXPIRED → 1000

3 passed, 0 failed — exit 0

🎓 GRADUATE

✏️ Quick check 1

The capstone’s expected coupon totals come from where — running the shop, or the shop’s rules on paper?

✏️ Quick check 2

What does “deploying” your capstone suite actually mean? (what gets published)

✏️ Quick check 3

A test in your capstone flakes. Per the graduation rite, what’s the FIRST move?

teach it back

🗣️ Now teach it back

The final teach-back: describe your capstone suite to an interviewer in one minute — structure, auth, test selection, data strategy, the mock/unmock split, browsers, CI — and end with the flake story.

Write it as if your friend is sitting next to you. Saved to your journal — future-you will use these notes to teach others.

a few sentences, minimum — you’ve got this

to remember

The capstone = assembly, and assembly is the job: scaffold+config → POM → bottled auth → @smoke/@regression → data table → one mocked sad path (+ honest unmocked journeys) → chromium+webkit → CI green with a PUBLISHED report.

The graduation rite: your first flake, triaged calmly — alone ×20, trace, clinic, cure, README note. Handling it IS the credential interviewers probe for.

Pin the repo; README with the report link (the teach-back principle, portfolio edition). From console.log("hello") to a CI-guarded cross-browser suite — you are an automation tester. Now go teach someone Phase 0: that was always the third goal.