This project is read-only.

Debug Mocha unit tests

Dec 7, 2013 at 7:49 PM
This may be similar to this question but I have a project that I'd like to be able to start up the Mocha tests and step through with the VS debugger.

Any thoughts?
Dec 13, 2013 at 9:07 PM
Edited Dec 13, 2013 at 9:08 PM
I've gotten Mocha working when I run my solution. It breaks on errors thrown all nicely.
It does not show me its output though or when a test fails due to a timeout. Both of these are probably fixable, but it works well enough for me as is

Here's how I did it
  1. Install mocha globally "npm install -g mocha"
    ----Then In Project Properties----
  2. Set Node.exe path to C:\Users\ [YourUsername] \AppData\Roaming\npm\mocha.cmd
    I tried setting it to %UserProfile% but it didn't work... If you have suggestions I'd love to hear them!
  3. Start web browser: False
  4. Startup file C:\ [Path_To_My_Project_Home] \test
  5. Script arguments: --reporter doc > test.html
    This lets me get a html page with a bit more info on the tests. You may want to use a different reporter and save to txt
Dec 17, 2013 at 5:42 PM
Thanks SeanSaleh. That worked well for me.

Here's what I did.

node.exe path: C:\Users\{myName}\AppData\Roaming\npm\mocha.cmd (would be nice to use ~\AppData... instead - I'll create an issue for this)
node.exe arguments: <blank>
Script arguments: C:\Code\Approvals.NodeJS\test
Working direcory: . < that's a period
Launch URL: <blank>
Node.js port: <blank>
Start web brower on launch Not Checked
May 2, 2014 at 11:08 PM
My above steps don't work anymore. In VS 2012 with the april 4th release...

When I try to debug I get this dialog
Node.js Tools for Visual Studio
This version of Node.js () is not supported. Please upgrade to Node.js v0.10.20 or later.
but my node --version says v0.10.26

Any thoughts?
May 5, 2014 at 6:33 PM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.
May 5, 2014 at 6:37 PM
Sorry about this. This is an unfortunate side effect of additional checks we added for Beta. I filed an issue so we no longer try to validate the version of node if the debug executable isn't node.exe.
Jun 21, 2014 at 6:37 PM
I've currently got this working with the latest dev build ( )

I also have a work around for not being able to use ~\AppData, you can just use a user specific njsproj file
Just create ProjectName.njsproj.user in the project folder with the following (change your username of course):
<?xml version="1.0" encoding="utf-8"?>
<Project DefaultTargets="Build" xmlns="">
Sep 23, 2014 at 10:18 PM
FYI to debug using nodeunit (useful if you want to debug any npm packages that use it for their unit tests), you have to modify the nodeunit.cmd file. Nodeunit blindly grabs all arguments when it first runs including the arguments to node. Since Nodejstools passes --debug-brk as the last parameter, Nodeunit tries to pick it up. So we must modify the nodeunit.cmd file to move the --debug-brk as the first parameter.

Modify your C:\Users\YOURUSERNAME\AppData\Roaming\npm\nodeunit.cmd to this:
(*or if you don't want to modify the nodeunit.cmd file then create a new file called nodeunitdebug.cmd in the same directory and use that for your Node.exe path):
@echo off
set workingdir=%~dp0
set "args="
set "debugbrk="


if "%~1" neq "" (
  echo found arg: %~1
  if /i "%~1" neq "--debug-brk" (
    set args=%args% %1
  if /i "%~1" equ "--debug-brk" (
    set debugbrk=%1=%2
  goto :parse
if defined args set args=%args:~1%

@echo on

@IF EXIST "%workingdir%\node.exe" (
  "%workingdir%\node.exe" %debugbrk% "%workingdir%\node_modules\nodeunit\bin\nodeunit" %args%
) ELSE (
  echo allargs=%*
  node %debugbrk% "%workingdir%\node_modules\nodeunit\bin\nodeunit" %args%
  if /i "%pausewhendone%" equ "true" (
Then use these project settings:
  • Node.exe path: C:\Users\John\AppData\Roaming\npm\nodeunit.cmd
  • Node.exec arguments: blank
  • Working directory: .
  • Environment Variables: pausewhendone=true (NOTE: Set this if you want the unit test results to pause when done so you can read the results, otherwise leave it blank)
Also something to keep in mind. To get around the 256-character limit, I use a symbolic link to shorten the path and load my visual studio project from the symbolic link (you have to launch it from a command window or Visual Studio will resolve the full path). Debugging doesn't work, though, because it somehow "resolves" to the real path name and the breakpoints look like they are set in an external unused file.

To get around this, you would move your project to a directory that has a short path, and then create a symbolic link to that directory in the old project location.