Testing and Debugging
The Testing and Debugging domain tests whether you can prove code works and diagnose it when it does not: test layers, isolation, assertions, and the DevTools and workflow habits that shorten feedback loops.
Test layers
Unit tests are fast and numerous, integration tests check modules together, and end-to-end tests drive a real browser, making them slow and brittle - keep few of them. Structure each test arrange–act–assert with one behaviour per test, and name it for the behaviour rather than the function.
Doubles and coverage
A stub returns canned data, a spy records calls, a mock sets expectations, and a fake is a lightweight working implementation. Replace network, clock and randomness so results are deterministic. Line coverage shows what executed, not what was verified; a test with no meaningful assertion inflates coverage and catches nothing.
Async and flakiness
Await the promise or use the framework's findBy-style queries instead of sleep. Inject a clock or use fake timers rather than reading Date.now(). Flaky tests usually leak state between cases, depend on ordering, or assume real timing.
Debugging
In DevTools Sources, set line, conditional, DOM-mutation, event-listener and XHR/fetch breakpoints; inspect the call stack and scope panes; step over, into and out. A debugger statement pauses only while DevTools is open. Use the Network panel to inspect status, headers and payloads, and console.table or console.time for quick measurement. Reproduce first, then bisect with git bisect or by disabling half the code.
Worked example
A date test fails near midnight: expect(formatDate(new Date())).toBe('2024-03-05') depends on the wall clock. Inject the date - formatDate(new Date('2024-03-05T12:00:00Z')) - and the test becomes deterministic while still exercising the real branch.
Traps
Testing implementation details so refactors break tests, snapshotting large trees nobody reads, and chasing failures without a reproduction.