How much Testing do you already have?
Be honest — nobody is watching. This only decides which chapters come first; every chapter stays open to you either way.
“I can write a trustworthy unit test.”
Start with why we test at all, then the mechanics — assertions, structure, mocking, async — on plain functions before anything else.
- You've written a script and hoped it worked, rather than proved it
- You haven't used a test runner (Jest/Vitest) on your own project
- You want the testing pyramid and the basics once, in order
“I can test a real application.”
You can unit test a function. Now test a real app: components, APIs, databases, and the discipline (TDD/BDD) behind writing tests first.
- Comfortable with a test runner, assertions and basic mocks
- You've had a passing test suite miss a real bug
- You want tests that catch regressions, not just satisfy a coverage number
“I can design a test strategy.”
End-to-end, visual regression, contract and mutation testing — and the judgment call of what to test where, at the scale of a real system.
- You can already test components and APIs with realistic fixtures
- You've owned a flaky, slow suite that nobody trusted
- You want the why under contract testing and test architecture at scale
Not sure? Start at Beginner — every path opens at the section people usually skip.
Full syllabus
Everything each level eventually covers — ticked sections are written, the rest are still on the desk.
Beginner0 / 7 sections written
- Why we testcoming soon
The testing pyramid: unit / integration / e2e
- Unit testing fundamentalscoming soon
Jest/Vitest basics, assertions, the AAA test structure
- Testing pure functionscoming soon
The easiest case, and why it's a good place to start
- Mocking basicscoming soon
Mocking modules, functions and timers
- Testing async codecoming soon
Promises and async/await inside a test
- Code coveragecoming soon
What it measures, and what it can't tell you
- Running tests in CIcoming soon
The basics of wiring a test run into a pipeline
✅ Checkpoint: you can write a well-structured unit test suite for a small module, including async code and basic mocks, and read a coverage report honestly.
Intermediate0 / 9 sections written
- Test-driven developmentcoming soon
Red-green-refactor, in practice
- Testing UI componentscoming soon
Testing Library queries, user-event, testing behavior not implementation
- Testing APIs & backendscoming soon
supertest, integration tests against a real server
- Snapshot testingcoming soon
When it helps, when it just lies to you
- Fixtures & test datacoming soon
Factories, seeding, test isolation
- Mocking network requestscoming soon
Mock Service Worker (MSW) and friends
- Testing against a databasecoming soon
Test databases, per-test transactions, in-memory DBs
- Behavior-driven developmentcoming soon
Gherkin/Cucumber, surface level
- Flaky testscoming soon
Common causes, and how to actually fix them
✅ Checkpoint: you can test a component and its backing API end to end, with realistic fixtures and network mocking, and explain when a test is flaky vs actually broken.
Advanced0 / 8 sections written
- End-to-end testingcoming soon
Cypress vs Playwright, the page object pattern
- Visual regression testingcoming soon
Screenshot diffing, and its false positives
- Contract testingcoming soon
Pact, consumer-driven contracts between services
- Performance testingcoming soon
Load testing (k6/Artillery), benchmarking
- Accessibility testingcoming soon
Automated checks (axe) plus manual testing
- Test architecture at scalecoming soon
Organizing a large suite, parallelization
- Mutation testingcoming soon
Measuring test quality beyond coverage
- Test strategycoming soon
What to test where — the pyramid, in practice
✅ Checkpoint: you can design a test strategy for a multi-service system — what runs where, what's e2e vs contract-tested — and defend it against "why not just test everything end to end."
- This is the one topic on the shelf that's explicitly cross-stack — every other topic has its own testing chapter for that stack's tools, this one is about testing as a discipline: what to test where, and why.
- TDD gets its own intermediate chapter, not a beginner one, on purpose — red-green-refactor only clicks once you've written enough tests the boring way to feel the difference.
- Mutation testing and contract testing are the deepest, rarest layer — most working developers never reach for them, but the advanced tier doesn't skip them.