Tests on your laptop protect you. Tests in CI protect the whole team, on every pull request, whether or not someone remembered to run them. This last lesson puts the pieces together: a pipeline that runs the layers you’ve built in the right order, and the judgement about what deserves a test at all.
\nThe order matters as much as the content. Cheap checks that fail often go first, so a typo costs 30 seconds of feedback instead of 12 minutes:
\nHere it is as a GitHub Actions workflow:
\nname: Test\non:\n pull_request:\n push:\n branches: [main]\n\njobs:\n unit:\n runs-on: ubuntu-latest\n steps:\n - uses: actions/checkout@v6\n - uses: actions/setup-node@v6\n with:\n node-version: lts/*\n cache: npm\n - run: npm ci\n - run: npm run lint\n - run: npx tsc --noEmit\n - run: npx vitest run --coverage\n\n e2e:\n needs: unit\n runs-on: ubuntu-latest\n strategy:\n fail-fast: false\n matrix:\n shard: [1, 2, 3]\n steps:\n - uses: actions/checkout@v6\n - uses: actions/setup-node@v6\n with:\n node-version: lts/*\n cache: npm\n - run: npm ci\n - run: npx playwright install --with-deps\n - run: npx playwright test --shard=${{ matrix.shard }}/3\n - uses: actions/upload-artifact@v4\n if: ${{ !cancelled() }}\n with:\n name: playwright-report-${{ matrix.shard }}\n path: playwright-report/\n retention-days: 14A few details are doing real work:
\nneeds: unit means the end-to-end job starts only when unit tests pass. No point booting browsers for code that fails tsc.--shard=1/3 splits the Playwright suite across three machines that run in parallel. (For one combined report, switch to the blob reporter and run npx playwright merge-reports in a final job.)if: ${{ !cancelled() }} uploads the report even when tests fail, which is precisely when you need the traces from the debugging lesson.CI is set automatically on GitHub’s runners, so Vitest runs once instead of watching, a stray .only fails, and the Playwright config’s retries: process.env.CI ? 2 : 0 kicks in.Finally, in the repository settings, make these jobs required status checks on main, so a red pipeline actually blocks the merge. A pipeline nobody is required to pass is a suggestion.
Every test costs writing time, CI minutes and maintenance. Some cost more than they will ever catch:
\nexpect(CURRENCY).toBe('USD') restates the code).useState updates state, that Array.prototype.sort sorts, that your date library formats dates. Their maintainers test that.And be willing to delete. A test that has never failed for a real reason in two years, that breaks on every refactor, or that is permanently skipped, is a liability. Deleting it is a contribution.
\n\nYou now have every layer: static checks, unit tests that pin behaviour and boundaries, UI tests that act like users, end-to-end tests that wait correctly and stay isolated, and the tools to judge them, coverage for gaps and mutation testing for strength. The question behind all of it stays the same one from the first lesson: would this test fail for a bug someone could plausibly ship, quickly, with a message that says what broke? Keep the tests that answer yes, fix the ones that could, and delete the rest.
\nThe exercise asks you to make those calls on a real-looking list of tests.
\n","toc":[{"id":"sec-1","text":"A pipeline from fast to slow","level":2},{"id":"sec-2","text":"Choosing what not to test","level":2},{"id":"sec-3","text":"The whole picture","level":2}],"takeaways":["Order CI from fast to slow (lint and types, then unit and integration tests, then end-to-end) so cheap failures stop the run early.","Make the test jobs required checks on the main branch, upload Playwright reports as artifacts, and shard slow end-to-end suites across machines.","Keep the whole pipeline fast enough that people wait for it; a 40-minute pipeline gets bypassed.","Don’t test trivial code, framework or library behaviour, styling or implementation details; delete tests that never fail for a real reason.","A test earns its place when it would fail for a bug someone could plausibly ship, quickly and with a clear message."],"further":[{"title":"Playwright — Continuous Integration","url":"https://playwright.dev/docs/ci-intro"},{"title":"Playwright — Sharding","url":"https://playwright.dev/docs/test-sharding"},{"title":"GitHub Docs — About protected branches","url":"https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches"},{"title":"Vitest — Reporters","url":"https://vitest.dev/guide/reporters"}],"quiz":[{"q":"Your pipeline runs Playwright first (12 minutes), then lint (20 seconds). A typo in an import fails lint on most broken pull requests. What’s the better order?
","options":[{"text":"Keep the order; end-to-end tests are the most important, so they should run first.","why":"Importance isn’t the point; running the slowest job first means developers wait 12 minutes to learn about a 20-second problem."},{"text":"Lint and type check first, then unit and integration tests, then end-to-end only if those pass.","why":"Correct. Fast, cheap checks fail early and save runner minutes; the slow stage only runs on code that is already plausible."},{"text":"Run lint only on the main branch after merging.","why":"Then broken code reaches main before anyone notices, which is exactly what CI on pull requests exists to prevent."}],"answer":1},{"q":"Which of these tests is the best candidate for deletion?
","options":[{"text":"A regression test for a reported bug where'12.5' was parsed as 1205 cents.","why":"Regression tests for real bugs are among the most valuable tests you own; that bug happened once and can happen again."},{"text":"A test that renders a component and checks that React’s useState setter updates the state.","why":"Correct. It tests React, not your code. React’s own suite covers that, and the test can only fail if React itself is broken."},{"text":"An end-to-end test that adds an expense and checks the balances update.","why":"That’s a critical flow where the connection between UI, API and logic is the risk, exactly what end-to-end tests are for."}],"answer":1},{"q":"The end-to-end suite has grown to 30 minutes on one machine. What’s the most effective first step?
","options":[{"text":"Shard it across several machines with--shard, and check whether some end-to-end tests duplicate lower-level ones.","why":"Correct. Sharding cuts wall-clock time immediately; moving duplicated checks down the trophy cuts the total work."},{"text":"Run the end-to-end suite only once a week.","why":"Then a week of changes lands before anyone learns that a critical flow broke, and finding the culprit gets much harder."},{"text":"Increase the timeout of every test so fewer of them fail.","why":"Timeouts aren’t the problem here, and longer ones make a slow suite slower when something does go wrong."}],"answer":0}],"exercise":{"kind":"choice","multiple":true,"options":["page-snapshot","negative-format","usestate","settle-e2e","constant","private-spy","regression","network-404"],"correct":["page-snapshot","usestate","constant","private-spy"],"title":"Keep, or delete?","prompt":"You’ve inherited Splitwise-lite’s test suite. CI takes 25 minutes and the team wants it faster without losing confidence. Select every test you would delete (or not write in the first place). Leave the ones that earn their place unselected.
\n","hints":["For each test, ask: what plausible bug would make it fail? If the answer is “only a refactor” or “only a bug in React”, it is a candidate.","Regression tests for real bugs and tests of money edge cases are rarely the ones to cut."],"explanation":"Delete four. The whole-page snapshot fails on every markup tweak and teaches people to press “update” without reading. The useState test checks React, not Splitwise-lite. The constant test restates a line of code and can only fail when someone changes the value on purpose. The spy on a private helper fails on refactors and passes on real bugs. Keep the other four: the negative-amount format is a money edge case; the settle-up end-to-end test covers the flow where UI, API and logic meet; the regression test documents a bug that really shipped; and the 404 test covers error handling that users hit on bad links. To speed up CI, combine these deletions with sharding and moving duplicated end-to-end checks down to component tests.
expect(container).toMatchSnapshot() on the entire rendered group page (a 400-line snapshot).","why":"Delete. It fails on every harmless markup change and says nothing about which behaviour matters, so reviewers rubber-stamp updates."},"negative-format":{"text":"expect(formatMoney(-505)).toBe('-$5.05')","why":"Keep. Negative amounts and padding are exactly where money formatting breaks, and the test runs in a millisecond."},"usestate":{"text":"A test that renders a component, calls its useState setter through a test hook and checks the state changed.","why":"Delete. It tests React’s own behaviour, which React’s suite already covers; it can’t fail because of your code."},"settle-e2e":{"text":"A Playwright test: add an expense, click Settle up, expect “Everyone is settled up”.","why":"Keep. It is the core flow, and only an end-to-end test checks that the UI, the API and the settle-up logic work together."},"constant":{"text":"expect(DEFAULT_CURRENCY).toBe('USD')","why":"Delete. It restates the source. It only fails when someone changes the constant deliberately, and then it just needs updating too."},"private-spy":{"text":"A test that spies on the internal _sortDebtors helper and asserts it was called exactly once by settleUp.","why":"Delete. It locks in an implementation detail: inlining or renaming the helper breaks it, while a wrong settlement would pass."},"regression":{"text":"A regression test from last spring’s bug report: expect(parseAmount('12.5')).toBe(1250).","why":"Keep. This bug actually shipped once; the test makes sure it never returns silently."},"network-404":{"text":"A test that loadGroup rejects with “HTTP 404” when the API answers 404.","why":"Keep. Error handling is where bugs hide, and broken or old links make 404s a real user path."}}},"words":633,"readMinutes":3}