All topics
95 / 100
Testingbeginner

Debugging with the Browser DevTools Debugger

Using breakpoints, the call stack panel, and watch expressions in browser DevTools to pause execution and inspect program state at a specific point.

A debugger pauses execution so you can inspect the state at that moment. It replaces most console.log work.

Using the debugger is like pausing a live orchestra performance mid-piece to walk up and inspect exactly which notes each individual musician is currently holding and where they are in their own sheet music (the call stack), rather than only being able to listen to a recording afterward and guess, from the overall sound (console.log output), what any specific musician must have been doing at any given moment.

Key Concepts

1
Setting a breakpoint.
    click the line number in Sources
    debugger;                          // in the code
    conditional breakpoint             right-click -> Add condition
    logpoint                           logs without pausing
2
The conditional breakpoint is the one that saves time.
    i === 847 && item.status === 'ERROR'
3
Stopping on the one iteration that matters, rather than stepping through 846 that do not.
4
A logpoint logs a message without stopping, which is a console.log you did not have to add, commit, or remember to remove.
console.log
5
Stepping.
    step over    run this line, do not enter the function
    step into    enter the function being called
    step out     finish this function, stop at the caller
    resume       continue to the next breakpoint
6
The call stack panel is where the real answer usually is. It shows who called what. Clicking a frame shows that frame's variables, which is how you find where a bad value came in.
7
Scope shows what is in each scope — local, closure, global — and the closure section is how you check what a callback actually captured.
8
Watch expressions evaluate as you step:
9
    user.permissions.length
    items.filter(i => i.error).length
10
The breakpoints that find things you cannot locate.
    XHR/fetch breakpoint    stop when a request URL matches
    DOM breakpoint          stop when an element's attributes or
                            subtree change
    event listener          stop on any click, anywhere
11
The DOM one answers "what is changing this element" when the code doing it is not yours.
12
console methods worth knowing beyond log.
    console.table(arr)      arrays of objects, readably
    console.time / timeEnd
    console.trace()         how did we get here
    console.count()
consolelog
13
The workflow. Reproduce, set a breakpoint before the problem, inspect the state, step forward. Adding logs and rerunning is slower and tells you less — you see only what you thought to print.
14
What the interviewer is probing.1. "When is a breakpoint better than a console.log?" Probing: the technique. Stalls: "Never, logs are faster." Moves up: when you need the whole scope at a moment, or to step through control flow — a log shows one value at one point.
15
2. "What is a conditional breakpoint for?" Probing: the practical use. Stalls: "Nothing." Moves up: breaking only on the iteration or id that matters, instead of stepping through a thousand.
16
3. "How do you debug minified production code?" Probing: source maps. Stalls: "You cannot." Moves up: source maps map it back to the original source, which is why you generate them even for production.
17
4. "What catches an error you cannot reproduce?" Probing: the tools. Stalls: "Logs." *Moves up:* pause on exceptions, including caught ones, plus a logpoint that records without stopping.
Use cases:debuggingdevtoolsfundamentals