Review, Stretch Goals, and Next Steps

You've built the suite. This lesson is the review and the launch — a self-assessment checklist to confirm the suite is portfolio-ready, reflection questions on the architectural choices you made (so you can defend them in an interview), the stretch goals that turn a strong capstone into a standout one, and a roadmap of where to go next once Playwright is in your toolkit. Treat this lesson as the moment between "I finished a course" and "I'm a Playwright engineer" — the difference is whether you can explain the why behind every line of your project, not just the how.

Self-assessment checklist

Run through every item before you call the capstone done. Each item maps directly to something a senior reviewer or hiring manager will check.

Project setup

• tsconfig.json is in strict mode ("strict": true).
• playwright.config.ts configures three browsers, retries in CI, trace: 'on-first-retry', and a sensible reporter array.
• .gitignore excludes node_modules, playwright-report/, test-results/, playwright/.auth/, and .env.
• .env.example documents every environment variable; the real .env is git-ignored.

Architecture

• Tests don't reach into the DOM directly — they go through page objects.
• Page objects don't make assertions (assertions live in tests; page objects own actions and locators).
• Custom fixtures wrap storage state and page objects; tests just say ({ dashboard }).
• Authentication runs once via auth.setup.ts and is reused across every test.

Coverage

• 30+ tests across the six categories from the brief.
• API tests use the request fixture, not the page UI.
• At least three tests use page.route for network mocking (slow API, failure, session timeout).
• Visual regression covers at least three screens.
• Accessibility scans run on at least three pages and fail on serious/critical violations.

Quality

• --repeat-each=5 --workers=4 produces 0 flakes locally.
• No hard-coded credentials or API keys.
• Every test has a clear, scenario-driven name ("insufficient funds shows error" not "test1").
• Test files mirror the application structure (auth.spec.ts, transfer.spec.ts, etc.).

CI/CD

• GitHub Actions workflow runs on push and PR.
• Matrix sharding × browsers (4 × 3 = 12 jobs minimum).
• fail-fast: false so all shards run even on failure.
• Blob reporter on each shard, merge-reports job produces unified HTML.
• HTML report uploaded as artefact with 14-day retention.

Documentation

• README with: project purpose, architecture overview, how to run locally, how to interpret CI failures, environment variables.
• Inline comments only where the why is non-obvious (avoid comments that just restate the code).

If every box is ticked, you have a portfolio piece worth pointing to. If three or more aren't, spend another day before pushing public.

Reflection questions — defending your architecture

In a senior interview, you'll be asked why you made each choice, not just what you did. Practice answering these out loud:

Why fixtures over beforeEach? Fixtures are scoped explicitly (test or worker), composed via dependency injection, and self-clean via the use pattern. beforeEach mutates global state, runs in a fixed order, and leaks setup across describe blocks. Fixtures also make page objects available as if they were native parameters — ({ dashboard }) reads better than let dashboard: DashboardPage; beforeEach(() => { dashboard = new DashboardPage(page); }).

Why storage state over UI login? Each UI login takes ~3-5 seconds. With 30 tests × 3 browsers × 4 shards = 360 logins per run, that's 18-30 minutes of pure login time on CI. Storage state runs login once per role, then every test starts already authenticated. Performance compounds — and the auth UI gets its own dedicated tests, which is cleaner than re-testing it as a side-effect of every other test.

Why HAR / mocks over real APIs for some tests? Real APIs introduce flakiness (rate limits, transient failures, environmental drift) and make negative-path tests nearly impossible (you can't make a real API return 500 on demand). Mocks let you assert "what happens if the payment API returns 500" deterministically and without external dependencies. Real APIs still belong in dedicated end-to-end smoke tests; mocks belong in functional tests where you control the inputs and assert the UI behaviour.

Why getByRole over getByTestId? Role-based locators test what the user actually sees and what assistive technology consumes — they double as accessibility coverage. data-testid tests an internal contract between the test and the developer; if the role attribute is missing or wrong, your tests still pass but real users can't use the page. Default to getByRole and getByLabel; fall back to data-testid only when there's no semantic alternative.

Why parallel + sharding instead of one or the other? Parallel workers maximise a single machine; sharding spreads across multiple machines. Together they multiply: 4 shards × 2 workers per shard = 8x parallelism. Workers alone hit a CPU ceiling around 2-4 on standard runners; shards alone pay the per-machine setup tax repeatedly. The combination is the cost-efficient path to wall-clock speed.

Why trace 'on-first-retry' and not 'on'? 'on' doubles CI runtime and produces multi-gigabyte artefacts. 'on-first-retry' is zero overhead on green tests and full information on red ones — exactly what you want. The trade-off: a flake that passes on the first try has no trace recorded, but the same test will retry the next time it fails and you'll get the trace then.

Why fail-fast: false on the matrix? Without it, the moment one shard fails GitHub kills the others, and you lose visibility into whether the failure is one-test-broken or whole-suite-broken. fail-fast: false keeps every shard running so the merged report shows everything that's wrong, not just the first thing.

If you can answer these in your own words, you understand the suite at the architecture level — not just the code level.

Stretch goals

Pick one or two if you're aiming high:

Mobile emulation. Add a mobile-chrome project using devices['Pixel 7']. Run a subset of flows (login, dashboard, transfer) on it. Add a mobile-safari using devices['iPhone 14']. Real banking apps must work on phones; this signals you understand responsive testing.

Allure reporting. Wire up allure-playwright, tag tests with epic, feature, severity, owner. Generate the report and link it from the README. Allure's history view (flake rate over time, failure clustering by feature) is what separates a portfolio piece from a polished portfolio piece.

Performance assertions. Use page.evaluate(() => performance.timing) or the performance.measure API to assert dashboard load is under 3 seconds and key API responses under 1 second. This crosses into performance testing — a credible adjacent skill.

Dockerised CI. Replace the ubuntu-latest + npx playwright install setup with mcr.microsoft.com/playwright:v1.50.0-jammy as the base image. Compare runtime — Docker variant is typically 60-90 seconds faster per shard.

Slack reporter. Hook the custom Slack reporter from Chapter 9 so failed tests post to a channel with the test title, browser, and a link to the artefact. Real teams expect this.

PR comment automation. Use gh pr comment from a workflow step to post the merged report URL and pass/fail summary onto every pull request. Reviewers see "Playwright: 287 passed, 0 failed, 1 flaky → report" inline with the diff.

Visual diff reviews. Adopt a service like Argos CI or Chromatic to host visual baselines and surface diffs as PR checks. The toHaveScreenshot baselines from your project plug in directly.

Stretch goals are optional but each one is the kind of thing that makes a recruiter pause on your repo for an extra minute.

Build a portfolio that actually opens doors

A great capstone repo has three properties:

1. Public on GitHub with a permissive license and clear README.
2. Linked from your CV / LinkedIn with one sentence summarising scope: "Playwright TypeScript suite for a banking app — 30 tests across 3 browsers, sharded CI, visual regression, axe-core a11y, full trace-based debugging."
3. A short Loom or recorded demo (under 3 minutes) walking through: the test list, the page-object architecture, a CI run, and the trace viewer for a failed test.

That last one is the differentiator. Most candidates link a repo and hope hiring managers click. A Loom embedded in your CV gets watched, and three minutes of you talking confidently about your own architecture beats any number of bullet points.

Where to go next

If you're early-career, the next move is breadth — pick up Playwright with Python or C# so you're not locked into one stack. Mid-career: depth — the AI testing course and CI/CD course build the systems-level skills that separate a strong tester from a test architect. Senior: leadership and architecture — Playwright is now a tool in your kit; the next chapter of your career is about choosing tools, designing strategies, and mentoring teams.

Coming from Cypress?

If you got here via the Cypress course, you now have both frameworks in your toolkit. The reality of testing in 2026:

• Cypress is still the better choice for component testing (its component runner is more mature) and for teams already invested in its ecosystem.
• Playwright is the better choice for greenfield E2E projects, multi-browser requirements, and CI-heavy pipelines (the trace viewer is genuinely category-defining).
• The skills overlap is huge — page objects, fixtures, mocking, assertions all transfer cleanly. Don't pick a side; pick the right tool per project.

Strong testers know both; strong test architects know which to pick when.

⚠️ Common mistakes

• Treating the capstone as homework, not a portfolio piece. A capstone tucked in a private repo nobody sees is wasted effort. Push it public, link it from your CV, talk about it in interviews — the project is only valuable if people see it.
• Skipping the README. Reviewers spend ~30 seconds on each repo. A great test suite with no README looks worse than a smaller suite with clear documentation. Spend an hour on the README; it's the highest-ROI hour of the whole capstone.
• Stopping the moment the course ends. The fastest learners keep one Playwright project alive after the course — extending it monthly with new features, new patterns, new CI tricks. Treat your capstone as a living portfolio, not a finished assignment.

🎯 Practice task

Close out the course in three steps. 1-2 hours.

1. Self-review. Walk every item in the checklist above. Anything failing → fix before submitting. Anything you can defend but didn't include → write a short "design decisions" section in the README explaining the trade-off.
2. Public push and demo. Make the GitHub repo public. Record a 3-minute Loom: open the repo, walk through tests/, show one page object, run one test locally, open the HTML report, click a trace. This recording is the artefact you link in interviews.
3. Pick a next step from the concept map and start it within a week. The fastest learners turn course completion into immediate next-course enrolment. Pick one — Playwright Python, Playwright MCP, K6, or CI/CD for QA — and start the first lesson. Momentum compounds.

You've now built one of the most ambitious automation portfolios anyone leaves a Playwright course with. Treat that as the floor of what you're capable of, not the ceiling. The course is over; your career as a Playwright engineer is just starting. Congratulations — and ship something with this.