← Back to JavaScript
12

Debugging in JavaScript: find the exact bug before touching the code

Learn professional debugging with breakpoints, console traces and stack trace reading so you can fix errors with method instead of guesswork.

📘 Theory

A debugging mindset: understand first, fix second

Fixing without diagnosis often creates new bugs.

A bug almost always follows a pattern: unexpected data, the wrong order of execution or an invalid assumption. Before editing code, you need to observe the real values moving through the system.

A useful strategy is simple: reproduce the bug, collect evidence such as logs or stack traces, isolate the smallest area, fix it and then verify against regression.

1

1) Reproduce

Make the bug appear consistently.

  • Same data
  • Same steps
  • Same environment
2

2) Observe

Record the state before the failure.

  • console.log
  • breakpoints
  • watch variables
3

3) Isolate

Reduce the problem to the smallest useful part.

  • One concrete function
  • One minimal input case
  • No extra noise
4

4) Verify

Confirm that you fixed the cause and not only the symptom.

  • Retest the original case
  • Retest edge cases
  • Check that no other flow broke

A smart console: logs that really help

A good log answers one concrete question.

1

Do not flood the console with noise. Every trace should help you validate one hypothesis: the expected value, the expected type or the executed branch.

2

A good pattern is label plus key data plus phase context. That way, if you read fifty lines, you still understand the sequence quickly.

Breakpoints and `debugger`: inspect the code in real time

When a log is not enough, pause execution and look inside.

A breakpoint freezes execution right before the problem so you can inspect variables, the call stack and the step-by-step flow.

The `debugger` statement creates that same pause if DevTools is open, which is useful for temporary inspection during development.

  • Step over moves to the next line without entering a called function.
  • Step into enters the called function.
  • Step out finishes the current function and returns to its caller.

Read a stack trace without panic

The trace tells you the path the bug followed.

1

A stack trace lists the functions involved from the thrown error back through the call chain. Do not start with the last line you see. Start with the first reference to your own business code.

2

When an error begins with invalid data, the stack helps you locate which function assumed something that was not actually true.

Debugging antipatterns you should avoid

Do not cover up errors. Understand them.

1

Antipattern one: commenting out random lines until the code seems to work. Antipattern two: adding an empty `try/catch` only to hide the error. Antipattern three: fixing the symptom without testing edge cases.

2

A practical rule is simple: every fix should answer a proven cause. If you cannot explain the cause, the debugging process is not finished.

🧪 Learn by doing

Example Guided example: detect `NaN` in a cart total Use logs and validation to see why the total becomes `NaN`.
Example Guided example: why it enters the wrong branch Debug a condition that fails because an API returned an unexpected type.
Example Interactive demo: guided debugging lab Trigger common bugs and inspect the clues in the console to identify the root cause.

🏁 Challenges

Challenge Challenge 1: add useful traces to isolate the bug Insert strategic logs to detect why a sum returns `NaN`.
Challenge Challenge 2: fix a condition after debugging the type Adjust a condition that never matches because the type is not what you assumed.

What is this?

I'm Cristian Eslava and I sometimes build websites so both you and I can learn and experiment. culTest

I made this in February 2026 to make learning easier for my students. The idea is to learn web development by practicing and to keep expanding the project with new topics, tests and challenges.

It draws inspiration from MDN, W3Schools, CodePen, Manz and many other web development references. I wanted to combine useful theory, runnable examples, challenges and the testing system I had already built for culTest. culTest

If you liked it, if you didn't, or if you want to get in touch, write to me at cristianeslava@gmail.com