Project Brief — Full E2E Test Suite for an E-Commerce Application

You've worked through nine chapters. Selectors, navigation, network stubbing, custom commands, page objects, sessions, CI, framework architecture — every Cypress pattern that matters in real work. The capstone pulls every one of them into one project: a production-ready test suite for an e-commerce web application called ShopEasy. This first lesson is the brief — the application's surface area, the deliverables you'll produce, and the rubric that maps each deliverable back to the chapter where the skill was taught. The next lesson walks through the build step by step; the third reviews and points to stretch goals.

The application — ShopEasy

ShopEasy is the kind of web app every QA engineer's portfolio should have a test suite for: not too small to be unrealistic, not too large to fit in a weekend. Imagine — or build — a typical mid-sized e-commerce site with seven core areas:

1. Product listing. A /products page with cards, search input, category filters, price-range filters, and sort-by-price/popularity controls.
2. Product detail. /products/:id with images, description, price, quantity selector, "Add to cart" button, related products.
3. Shopping cart. /cart with line items, quantity update, remove buttons, totals, checkout CTA.
4. Authentication. /login, /register, /logout. Email + password. Session persists across page reloads.
5. Multi-step checkout. /checkout/shipping → /checkout/payment → /checkout/review → /checkout/confirmation. Each step has its own form and validation.
6. Account. /account/orders showing order history; /account/settings for profile updates.
7. Admin panel. /admin/products with create/edit/delete; /admin/orders with status changes; admin-only access guarded by role.

If you don't have a real ShopEasy to test against, two equally valid options:

• Use Sauce Demo (https://www.saucedemo.com) as the target. It covers most of the surface (products, cart, checkout) and has stable data-test attributes throughout.
• Build a minimal ShopEasy yourself. A Vite + React + Zustand setup with a stubbed JSON-server backend takes a few hours and gives you full control over the app actions, data-testids, and edge-case routes.

Either approach works. The point of the capstone is the test framework, not the app under test.

Deliverables — the eleven artefacts

Your final project should ship these eleven things, organised exactly the way chapter 9 lays out a production framework:

1. A scaffolded Cypress project with TypeScript: cypress.config.ts, cypress/tsconfig.json, multi-target environment config (chapters 1, 2, 5).
2. TypeScript type definitions for the core data models in cypress/support/types.ts: User, Product, CartItem, Order, ApiResponse<T> (chapter 9, lesson 2).
3. Test data factories in cypress/utils/factories.ts with createUser, createProduct, createOrder, createOrderWithProducts, using @faker-js/faker for realistic data and timestamp+counter for uniqueness (chapter 9, lesson 3).
4. Page objects in cypress/pages/ for at least four pages: LoginPage, ProductListPage, CartPage, CheckoutPage. Object-style or class-style — pick one and stay consistent (chapter 5, lesson 2).
5. Custom commands in cypress/support/commands/ split by feature: auth.ts, cart.ts, admin.ts, plus index.ts re-exports. Typed via declare global { namespace Cypress { interface Chainable { ... } } } (chapter 5, lesson 1).
6. API helpers in cypress/utils/api.ts for backend setup: seedUserViaApi, seedProductsViaApi, clearTestData (chapter 4, lesson 4).
7. At least 25 test cases across these categories:
   • Authentication (5) — login happy path, login with bad credentials, registration with valid data, logout clears session, session persists across reload.
   • Product browsing (5) — list renders, search filters by name, category filter narrows results, sort by price ascending, product detail loads with correct data.
   • Cart management (5) — add item, remove item, update quantity, empty cart shows empty state, cart contents survive page refresh.
   • Checkout flow (5) — full happy path, shipping form validation, payment API failure path, guest checkout (no login), confirmation page shows order number.
   • API tests (5) — GET /api/products returns expected shape, POST /api/orders creates an order, GET /api/users/me requires auth, DELETE /api/orders/:id is admin-only, error response on invalid payload.
8. cy.intercept stubs for at least three edge cases — empty product list (returns []), checkout payment failure (returns 500), slow product list (delay 3s) (chapter 4, lesson 2).
9. Accessibility checks via cypress-axe on at least three pages — homepage, product detail, checkout. Filter on critical + serious impact (chapter 7, lesson 3).
10. Mochawesome reporting configured with the merge + marge pipeline. Screenshots attached on failure (chapter 7, lesson 4).
11. GitHub Actions workflow at .github/workflows/cypress.yml running on PR and nightly schedule, uploading artefacts on failure (chapter 8, lesson 1).

Stretch goals (optional)

Three add-ons that turn the project from "complete" to "showcase":

• Visual regression with cypress-image-snapshot or Percy on three key pages (chapter 7, lesson 2).
• Parallel execution in CI with a four-container matrix (chapter 8, lesson 3).
• Cypress Cloud integration with record: true and flake detection (chapter 8, lesson 4).

These are the differentiators. A team reviewing your portfolio will look at the capstone and decide whether you understand only the basics or whether you've built the kind of suite they'd actually want at work.

Capstone deliverables, mapped to chapters

How long this should take

Based on the time the practice tasks took: a focused weekend to build the framework and the auth/product/cart tests; a second weekend for checkout, admin, accessibility, reporting, and CI. Don't try to do it in one sitting — the value comes from making each layer right, not from rushing.

If anything in the brief is unfamiliar, the chapter map above tells you exactly where to refresh. Each deliverable was the focus of a specific lesson; a quick re-read is faster than reinventing the pattern.

Acceptance criteria — how you'll know you're done

The capstone is complete when all eleven deliverables exist and:

• npm run cy:run passes locally with at least 25 tests green.
• npm run cy:report produces a Mochawesome HTML you can open in a browser.
• The GitHub Actions workflow runs on a PR and posts a green check.
• A teammate (or your future self) can clone the repo, run npm install, follow a one-line README to get tests running, and read the test names to understand what the suite covers.

The fourth bullet is the real one — a test suite that's hard to onboard into is a test suite the team will end up rewriting in six months. A teammate who's never seen the codebase should be able to add a new login test in fifteen minutes.

Submitting and reviewing

Push the project to GitHub. Make the README the front door — install steps, environment-variable list (with a cypress.env.example.json checked in), one paragraph explaining the folder structure, one paragraph explaining how to run smoke vs full vs CI. Add a screenshot of the Mochawesome report and the GitHub Actions tab.

The next lesson walks through each step of the build with concrete code. The third lesson is the self-assessment checklist and the stretch goals — and where to go after this course.

🛠️ Project work

This is the entire capstone. The "practice task" for this lesson is to read the brief end to end and pick your target app. Either commit to using Sauce Demo or scaffold a minimal ShopEasy yourself. Set up the empty folder structure (cypress/, pages/, utils/, support/, e2e/{auth,products,cart,checkout,admin,api,smoke}/) so the next lesson lands on a project ready to fill in.

Then read lesson 2 — the guided walkthrough — and start building. Don't try to write tests before the framework layer (types, factories, commands, page objects) is in place; the framework is what makes the tests fast to write and easy to maintain. By the end of lesson 2 you should have the full skeleton with three reference test files; lesson 3 is the review pass that polishes it into a portfolio piece.