Specialization
Testing & Debugging
Writing code that works once is easy — writing code you can prove works, and can quickly find and fix when it breaks, is what separates a hobby project from professional software. This module covers the modern 2026 testing stack end to end (Vitest, Playwright, and where each fits), the discipline of test-driven development, and the debugging skills every engineer uses daily, whether they're fixing a failing test or a live production incident.
Topic Map
Everything in this module, at a glance
In Depth
Every topic, explained — with real-world industry context
Testing Fundamentals & the Testing Pyramid
Before any specific tool, you need a mental model for what kinds of tests exist and how many of each a healthy codebase actually has.
Basics
- Why we test — catching bugs before users do
- Manual testing vs. automated testing
- The three main test types: unit, integration & end-to-end
- What makes a good test — fast, isolated & repeatable
Intermediate
- The testing pyramid — roughly 70% unit, 20% integration, 10% E2E
- Deciding what actually deserves an E2E test vs. a unit test
- Flaky tests — what causes them & how to fix them
- Test naming & organizing a growing test suite
Advanced
- Designing a testing strategy for an entire codebase, not just one feature
- Balancing test suite speed against thoroughness at scale
- Testing strategy for legacy code with no existing tests
- When to intentionally under-test (and why that's sometimes correct)
Real-World Industry Use Case
The 70/20/10 pyramid (70% unit, 20% integration, 10% E2E) is the specific heuristic real teams use in 2026 — comprehensive unit tests for business logic, integration tests for data access and API routes, and a focused 20-30 E2E tests reserved only for the paths where a failure would actually cost the business money.
Unit Testing — Vitest & Jest
A unit test checks one small piece of logic in isolation — the fastest, cheapest, most common type of test, and the foundation everything else builds on.
Basics
- Writing your first test — arrange, act, assert
- Test runners — Vitest & Jest
- Assertions & matchers
- Running tests locally & in watch mode
Intermediate
- Testing pure functions vs. testing code with side effects
- Setup & teardown — beforeEach/afterEach
- Snapshot testing, and its real limitations
- Testing React components (React Testing Library)
Advanced
- Structuring a large unit test suite for maintainability
- Testing edge cases & error paths deliberately, not just the happy path
- Performance of the test suite itself at scale
- Migrating an existing Jest suite to Vitest
Real-World Industry Use Case
Vitest has become the 2026 default for anything below the browser — benchmarks show it finishing 10,000 React component tests roughly 3.8x faster than Jest, with about 40% lower memory overhead, which is exactly why most new projects no longer start with Jest.
Integration & API Testing
Integration tests check that multiple pieces — your code and a real (or realistic) database, or two internal services — actually work together correctly.
Basics
- What integration testing checks that unit testing can't
- Testing an API route end to end (request in, response out)
- Using a real test database vs. an in-memory one
- Seeding & cleaning up test data between runs
Intermediate
- Testing data access layers & ORM queries
- Test fixtures & factories for consistent test data
- Testing authentication-protected routes
- Isolating integration tests so they don't interfere with each other
Advanced
- Contract testing between independently-deployed services
- Running integration tests reliably in CI (containerized test databases)
- Testing message queue / async workflows
- Balancing integration test coverage against runtime cost
Real-World Industry Use Case
The 2026 testing strategy that consistently works in practice is comprehensive integration tests specifically for data access and API routes — this is precisely the layer where unit tests are too narrow and E2E tests are too slow to run for every case.
End-to-End Testing — Playwright & Cypress
End-to-end (E2E) tests drive a real browser through a real user flow — the slowest, most realistic, and most expensive tests, reserved for what matters most.
Basics
- What E2E testing simulates — an actual user clicking through the app
- Writing a first E2E test — Playwright or Cypress
- Selecting elements reliably (avoiding brittle selectors)
- Running E2E tests headless vs. headed (visually)
Intermediate
- Testing critical business flows — signup, checkout, payment
- Handling async waits & loading states in E2E tests
- Visual regression testing
- Cross-browser testing (Chromium, Firefox, WebKit)
Advanced
- Parallelizing & sharding E2E suites for CI speed
- Debugging a flaky E2E test in a CI environment
- Choosing exactly which 20-30 flows deserve E2E coverage
- Integrating E2E tests into a deployment pipeline as a release gate
Real-World Industry Use Case
Playwright has overtaken Cypress on essentially every metric in 2026 — roughly 33M vs. 6.5M weekly npm downloads — thanks to real WebKit support and free built-in test sharding, making it the default choice for new E2E suites while Cypress remains common in existing codebases.
Test-Driven Development & Mocking
TDD flips the usual order — write the test first, watch it fail, then write just enough code to make it pass — and mocking lets you test code that depends on things you don't want to actually run in a test.
Basics
- The TDD cycle — red, green, refactor
- Why write a failing test first
- What a mock/stub/spy is, in plain terms
- Mocking a simple function dependency
Intermediate
- Mocking external API calls & network requests
- Test doubles — the difference between a stub, a mock & a fake
- Behavior-driven development (BDD) as an alternative framing
- Knowing when NOT to mock (over-mocked tests that test nothing real)
Advanced
- TDD for a non-trivial feature, start to finish
- Mocking time, randomness & other non-deterministic dependencies
- Designing code specifically to be more testable (dependency injection)
- The trade-offs of TDD on team velocity — when it helps and when it doesn't
Real-World Industry Use Case
Whether a team formally practices TDD or BDD, the underlying discipline — writing the expected behavior down before or alongside the implementation — is what these modern testing tools are built to support, and it remains one of the clearest ways to avoid shipping untested edge cases.
Debugging Techniques
Testing catches known risks in advance; debugging is what you do when something you didn't predict breaks anyway — a distinct and equally critical skill.
Basics
- Print/log-based debugging — fast, but limited
- Using a real debugger — breakpoints, step-over/step-into
- Reading a stack trace to find the actual failure point
- Reproducing a bug reliably before trying to fix it
Intermediate
- Debugging asynchronous code (a much harder category)
- Browser DevTools — network tab, console, and the debugger together
- Binary search debugging (`git bisect` and the same idea in code)
- Debugging a failing test vs. debugging a live application
Advanced
- Debugging a production issue you can't reproduce locally
- Using logs, metrics & traces together during a live incident (recap from DevOps)
- Root cause analysis — going past the symptom to the actual cause
- Writing a clear bug report / postmortem that prevents recurrence
Real-World Industry Use Case
Every debugging technique here — from print statements to reading a stack trace to root cause analysis — is used identically whether you're fixing a failing test suite locally or a live production incident at 2am; this module builds the muscle once so it transfers everywhere.
Code Quality, Coverage & CI Integration
Tests only create real value when they actually run automatically, on every change — and coverage/quality tooling tells you where the real gaps still are.
Basics
- Code coverage — what it measures, and what it doesn't
- Running the test suite automatically in CI on every push
- Linting & static analysis as a first line of defense
- Failing a build when tests fail
Intermediate
- Setting meaningful coverage targets (not chasing 100% blindly)
- Code review practices — what a good reviewer actually checks
- Pre-commit hooks for fast local feedback
- Writing maintainable code that's naturally easier to test
Advanced
- Mutation testing — checking whether your tests would actually catch a real bug
- Test impact analysis — running only the tests affected by a change
- Auditing an AI-generated test suite for real coverage vs. superficial coverage
- Designing a CI testing strategy for a large, multi-service codebase
Real-World Industry Use Case
Mutation testing has become table stakes specifically for validating AI-written test suites in 2026, and test impact analysis (via tools like Datadog, Bazel or Nx) is consistently cited as the highest-ROI CI investment most teams still skip — both are exactly the kind of practice that separates a mature engineering team from one just going through the motions.
Ready to learn this — live?
See how this module fits into the complete curriculum.