Review, Stretch Goals, and Next Steps

The framework is built; the tests are green; the report renders; CI posts a green check. This last lesson is the polish pass — a self-assessment checklist to make sure you actually did what the brief asked for, the reflection questions that separate a working project from one you understand, the five stretch goals that turn the capstone into a portfolio piece, and the courses on qa.codes that take you from "Cypress engineer" to "automation lead."

Self-assessment checklist

Read each line. If you can answer "yes" honestly, tick it. If not, the gap is where you go back.

Foundations. Tests run with npm run cy:open (interactive) and npm run cy:run (headless). Multi-target env (CYPRESS_TARGET=staging) routes the suite at the right host. cypress.env.json is gitignored; cypress.env.example.json is checked in.

Type safety. cypress/support/types.ts defines User, Product, Order, CartItem, ApiResponse<T>. Every custom command, page object, and factory imports from this single source. A typo in a property name is a compile error, not a runtime surprise.

Factories. cypress/utils/factories.ts exports createUser, createProduct, createOrder, createOrderWithProducts. Each one accepts a Partial<T> of overrides. Uniqueness is guaranteed by Date.now() + counter (or faker). No two tests collide on emails or IDs.

Commands. Typed via declare global { namespace Cypress { interface Chainable { ... } } }. At minimum: cy.apiLogin, cy.sessionLogin, cy.uiLogin, cy.addToCart, cy.checkout. The login spec uses cy.uiLogin; every other spec uses cy.sessionLogin.

Page objects. At least four: login, product list, cart, checkout. Element accessors are functions (never cached chainables). Composite actions (loginPage.login(...)) compose the smaller ones. Selectors live in cypress/utils/constants.ts.

Test count and coverage. At least 25 tests across five categories: auth (5), products (5), cart (5), checkout (5), API (5). Smoke folder picks 5-7 critical paths. Every spec is independent — no test depends on another's side effects.

Edge cases. At least three cy.intercept stubs covering empty state, error state, slow loading. Each one has its own it block with explicit assertions on the resulting UI.

Accessibility. cypress-axe runs on at least three pages. includedImpacts: ["critical", "serious"] in production; skipFailures: true only during initial retrofits. No global rule disables.

Reporting. Mochawesome HTML at cypress/reports/html/merged.html after npm test. Failure screenshots embedded inline. JUnit XML emitted alongside (via cypress-multi-reporters).

CI. .github/workflows/cypress.yml runs on PR + nightly. Artefacts upload on failure (screenshots, videos, HTML report). Secrets injected as CYPRESS_* env vars. Mochawesome report attached on every run.

If you missed any line, fix that piece before moving on. The next steps assume the foundation is solid.

Reflection questions

Read each question and write a one-paragraph answer. The exercise of explaining your decisions is what separates "I followed a tutorial" from "I built this."

• Why did you pick cy.sessionLogin over cy.apiLogin for most specs? What would change if you ran the suite serially on one CI worker — would the answer be different?
• Why are page-object accessors functions instead of cached chainables? What does Cypress's auto-retry do that breaks if you cache?
• Why does cypress/support/types.ts matter more than the eleven type interfaces in your factories file? What would go wrong if every factory file declared its own User?
• What's the trade-off of stubbing every API call in the checkout test? When would you swap one stub for a real cy.request setup?
• Why does the smoke suite live in its own folder instead of being tagged with @cypress/grep tags? What would each approach gain or lose if the suite grew to 500 specs?

These aren't trick questions. They're the questions a senior QA lead would ask in a code review of your capstone. Being able to answer them out loud is what makes the project a portfolio piece instead of a tutorial submission.

Stretch goals

Five additions that take the project from "complete" to "showcase". Pick the ones that matter most for your career direction.

1. Visual regression testing. Wire cypress-image-snapshot into the smoke suite. Baseline the homepage, product list, and checkout review page at desktop + mobile breakpoints. Confirm the baselines land in cypress/snapshots/ and are committed to git. Force a colour change in the app; watch the diff fail; approve or reject. The full setup is in chapter 7, lesson 2.

2. Parallel execution with Cypress Cloud. Sign up for a free Cypress Cloud account. Add record: true and parallel: true to the workflow. Confirm a four-container matrix splits specs by historical duration. Add retries: { runMode: 2 } and watch the Cloud's flake-detection dashboard mark intermittent tests. Chapter 8, lessons 3 and 4.

3. Custom Mochawesome reporter with screenshots. The walkthrough wires the basic screenshot attachment. Extend it: add a cy.evidence(name) custom command that captures cy.screenshot + addContext in one call, and use it at three meaningful points per checkout spec. The report becomes a stakeholder-readable visual walkthrough, not just a pass/fail dashboard.

4. Smoke suite under two minutes. Move five critical-path tests into cypress/e2e/smoke/. Strip every UI navigation that isn't load-bearing — use API setup for everything except the assertion. Run with npm run cy:run -- --spec "cypress/e2e/smoke/**" and confirm the wall-clock is under 120 seconds. Wire it as a separate workflow (smoke.yml) that runs on every push, alongside the full regression on PR + nightly.

5. TypeScript strict mode. Add "strict": true to cypress/tsconfig.json. Run npx tsc --noEmit and fix every error. The common offenders: untyped cy.then callbacks, optional-chain misses on interception.response, as any casts in factory overrides. After the fixes, the framework is type-safe end to end and refactors propagate via compile errors instead of runtime flake.

Each stretch goal takes 1-3 hours and adds a meaningful skill to your portfolio. Don't try to do all five — pick two or three that align with where you want your career to go.

Portfolio polish

Push the project to GitHub as a public repo. The README is the front door:

• One-line description: "Production-ready Cypress + TypeScript test suite for ShopEasy, an e-commerce reference application."
• Stack: bullet list with versions (Cypress 13, TypeScript 5, Node 20).
• Quick start: three commands — npm install, cp cypress.env.example.json cypress.env.json, npm run cy:open.
• Folder map: the chapter-9 layout with one-line descriptions.
• Test commands: cy:open, cy:run, smoke vs full, report generation.
• Screenshots: the Mochawesome report and a green Actions check.
• Architecture decisions: a paragraph on why you used cy.session over UI login, why you picked Mochawesome, why the suite is structured by feature.

A reviewer should be able to clone the repo and have tests running in under five minutes. The README is what makes that possible.

Where to go next

The Cypress + TypeScript stack is one major automation toolkit. Three more on qa.codes deepen the rest of your QA toolkit:

• Playwright fundamentals (coming soon) — the other major JavaScript-ecosystem framework. Different architecture (out-of-process, native multi-tab, locator-first), different idioms. Most automation engineers end up needing both. The transferable concepts you've built here (page objects, fixtures, factories, network mocking) apply directly; the syntax is different.
• API testing masterclass (coming soon) — cy.request is the tip of the iceberg. Contract testing, schema validation against OpenAPI, GraphQL test patterns, and dedicated tools like Postman, Insomnia, and Supertest are the deeper layer.
• Manual software testing — automation isn't everything. Exploratory testing, accessibility audits, cross-browser visual QA, and the test-design heuristics that find bugs no automated test would think to check. The complement to this course, not a replacement.

For the supporting cast — TypeScript depth, JavaScript fundamentals, Git workflows, fundamentals of testing as a discipline — the TypeScript for QA, JavaScript for QA, Git for QA, and Software testing fundamentals courses cover the rest of the qa.codes catalogue.

Skills mastered, paths forward

Congratulations

You've finished the most comprehensive Cypress course on qa.codes — ten chapters, forty-two lessons, a complete production framework. The patterns are in your hands: typed selectors, retry-aware assertions, request stubbing, custom commands, page objects, app actions, sessions, OAuth, screenshots, accessibility, Mochawesome, GitHub Actions, parallel execution, factories, folder structure, maintenance.

Most QA engineers learn Cypress piecemeal — a Stack Overflow answer here, a tutorial there, a half-understood pattern from a colleague's PR. You learned it as a whole. That's worth something on your CV; it's worth more on a real codebase.

Open the capstone repo on GitHub. Pin it to your profile. Link it in your CV. The next time someone asks "have you used Cypress?" you have a 25-test, CI-deployed, fully-typed answer ready to show them.

🛠️ Project work

Two final tasks:

1. Run through the self-assessment checklist above, line by line, ticking each item off your repo. Fix the gaps. The exercise reveals which patterns you fully internalised and which you copy-pasted — the second category is where your next learning hour goes.
2. Pick one stretch goal and ship it this week. Visual regression, parallel CI, smoke suite, Mochawesome polish, or strict TypeScript — any of the five is a portfolio differentiator. Commit it as a separate PR with a description that links back to the chapter that covered the underlying technique.

Then take the next course on the list. Automation is a craft you build over years, not a course you take once. Cypress is now in your toolkit; the rest of QA awaits.