VSCode comes jam-packed with some incredible tools to help you build your applications.
One such tool is the built-in debugger. This debugger can make life far easier when you are debugging Node.js applications!
In today’s post, we will create an incredibly simple Node.js application to sum two numbers and show how the debugger can be a powerful tool for help to run through your programs and identify issues.
We will initialise a new npm project and install jest from your root directory of choice and create some files to run things through:
Open your new
hello-vscode-nodejs-debugger folder in VSCode and you will be set to start adding files!
Setting up math.js and adding a simple test
math.js, add the following:
Here we are creating a basic
sum function that takes two arguments and returns the sum. We are also creating a contrived "helper" function that is a wrapper around
sum so it is not exposed from the file. You may already see what is wrong, but we will show how to do so with the VSCode debugger.
__test__/math.spec.js, add the following:
We are running one simple test that expects 1 + 2 to equal 3. Before running the test, let’s update our
package.json file to have a
I had added to simple scripts:
hello. Hello is a ridiculous example but it is there to demonstrate what we can do with the debugger later.
To confirm everything is happy, let’s run
npm test. You will get the following:
Oh no, it seems like
undefined! Every person and their dog probably knows where we went wrong, but let's find out the fun way using the VSCode Debugger!
Running the VSCode Debugger
If you select the
debugger icon in VSCode from the left-hand side panel, you will be confronted with a basic screen asking for configurations to get started.
You will want to select the
Node.js (preview) configuration. Once selected, you will actually see you have the option to run the scripts written in our
package.json file! Adding
hello was a silly way to demonstrate that all scripts show up there, but we will want to choose the debug the
Click the green play button to start debugging. Once it starts running, you’ll notice that a new set of icons will appear (as denoted in the image below) and the terminal will output that the debugger is attached.
It looks like it ran without doing anything! That is because we need to start using the
debugger keyword to help let VSCode know that we want to stop the debugger (or set breakpoints, but more on that later).
__test__/math.spec.js to have the following:
When we re-run our spec, you’ll notice that we pause at the debugger and get some more information!
On the left-hand side, we’ll start getting information on things like the variables, call stack, breakpoints (and a couple more). You’ll notice that under variables, it tells us that our local
res variable is currently undefined. We can start walking through our application and see this value change!
First, we need to understand the debugging icons.
From left-to-right, the icons mean the following:
- Continue: pressing this will continue execution until the next breakpoint or
- Step over: this will “step over” the current line and move onto the next. This is useful if you want to step over a function.
- Step into: as opposed to step over, on the line of a function, it will actually step into the function and move the debugger there.
- Step out: if we have stepped into a function, we can step back out using this button.
- Restart: you can restart the script being debugged with this.
- Stop: stop the debugger.
In our example, we will look to do the following:
- Step over the
- Step into the
- Step over a few lines and watch what variables are there.
- Step back to our test file.
- Come to a conclusion and fix the file.
Given what has been said above, we want to first click “step over” to put our highlight on the line
const res = findSumOfTwoNumbers(1,2):
Now, “step into” the function:
You will see that we have now been moved to our
math.js file and it is showing where execution is currently out. Our "variables" section on the left-hand side has been updated to show the local values at the moment where
a is 1 and
b is 2. Pretty neat!
sum function itself has no issues (spoiler alert), so we are just going to step over the current line for now.
However, now that we have, you’ll notice something strange — our variables section now shows that our return value for the function is
undefined! Surprise, surprise, we forgot to return
sum(a,b) from our function!
As you may have guessed, this is the issue. For now, what we want to do is add a breakpoint by clicking on the “bookmark” symbol in the gutter to the left-hand side of the line number 5. This will add a breakpoint for us (which you can confirm as it will now be added to our breakpoints section on the left-hand sidebar).
Step back out of the function now. This will bring us back to our test file.
You will notice our local
res value is still
undefined as expected since we did not return a value from
findSumOfTwoNumbers(1, 2);. Let's just hit the continue option in the debugger now to finish off the script run.
Fixing our script
Select the breakpoint
math.js under our breakpoints section in the debugger panel on the left-hand side. This will take us back to the line that caused issues!
Let’s now update it to return the value:
With that all out of the way, we can select the
restart option on our debugger to begin the process over again!
We will stop at the
debugger statement again, but lucky for us we can speed the process up this time since we added the breakpoint in the
math.js file. As mentioned earlier, the debugger will stop for the
debugger keyword or breakpoints! Let's hit continue and move to that breakpoint.
If we step over the breakpoint in
math.js, you'll now see that our return value is
3 as we want!
Understanding that this will return the value we want, we can hit continue again in the debugger options to finish executing the test.
This time you will see success in our test file:
Hooray! We managed to isolate the issue by walking through our code with the VSCode debugger!
This is just a light overview of the debugger. There are other cool features like “watching” variables that I did not dive into here.
Although the example was contrived, the same principles apply when tracing other variables in-depth.
Image credit: Sigmund
Originally posted on my blog.