Mocha breakpoints using Visual Studio Code

Question

Is it possible to add breakpoints to ones Mocha tests using Visual Studio Code?

Normally when debugging code one need to configure the launch.json, setting the program attribute to the javascript file to execute. I am not sure how to do this for for Mocha though.

Answer 1

In VSCode version 1.13.0 (macOS), they have it built-in under configurations -> Mocha Tests.

Answer 2

I've figured out a way to do this which I classify as a workaround. I expect the Visual Studio Code team to provide a more definitive solution for this but meanwhile this what I've done:

1. I've created a ./settings/mocha.js file which runs mocha programatically passing arguments as a list of files to be run. You can see the full file here;

2. I've created a launch config which will run the ./settings/mocha.js as the program and passes the files/file patterns we need to test as arguments:

   {
       "name": "Unit tests",
       "type": "node",
       "program": ".settings/mocha.js",
       "stopOnEntry": true,
       "args": ["test/unit/*.js", "test/unit/**/*.js"],
       "cwd": ".",
       "runtimeExecutable": null,
       "env": { }
   }
   

   Full launch.json example

So this is the equivalent of doing mocha test/unit/*.js test/unit/**/*.js and now we can use breakpoints in our mocha tests.

Answer 3

Here is an example of launch configuration (launch.json) from Microsoft, which works with Mocha and allows using the debugger.

Also, there is a description of how to use the --debug-brk option.

Finally, here is an alternative version of how to debug code with Mocha tests using tasks.json file of VS Code and Gulp task runner.

Answer 4

Did you know, that you just go into your launch config, put your cursor after or between your other configs and press ctrl-space to get a current, valid mocha config auto-generated?

Which works perfectly fine for me. Including stopping at breakpoints. ( I also had a prior, now outdated one, that did no longer for various setting-related reasons. )

As of VSCode 1.21.1 (March 2018) this yields:

{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Mocha (Test single file)",
      "type": "node",
      "request": "launch",
      "runtimeArgs": [
        "${workspaceRoot}/node_modules/.bin/mocha",
        "--inspect-brk",
        "${relativeFile}",
      ],
      "console": "integratedTerminal",
      "internalConsoleOptions": "neverOpen",
      "port": 9229
    }
}

On a side-note: debug-brk is deprectated (for anyone with Node >= Version 8 at least).

Answer 5

If you don't want to use --debug-brk+Attach or state an absolute path to your global mocha installation (which will brake if you keep your launch.json under version control and have multiple developers on different machines), install mocha as a dev dependency and add this to your launch.json:

{
  "name": "mocha",
  "type": "node",
  "request": "launch",
  "program": "${workspaceRoot}/node_modules/mocha/bin/_mocha",
  "stopOnEntry": false,
  "args": ["--no-timeouts", "--colors"], //you can specify paths to specific tests here
  "cwd": "${workspaceRoot}",
  "runtimeExecutable": null,
  "env": {
    "NODE_ENV": "testing"
  }
}

Full debugging support in your tests by just pressing F5.

--no-timeouts makes sure your tests don't time out because you stopped at a breakpoint, and --colors makes sure Mocha outputs colors even though it doesn't detect that VS Code supports colors.

Answer 6

When using Babel, or generating javascript files yet placing breakpoints in the source - you have to make sure to enable sourceMaps and define outFiles. Here's an example config that worked for me.

    {
        "name": "Mocha Test",
        "type": "node",
        "request": "launch",
        "program": "${workspaceRoot}/packages/api/node_modules/mocha/bin/_mocha",
        "cwd": "${workspaceRoot}/packages/api",
        "args": ["--colors", "--no-timeouts", "out/test"],
        "outFiles": ["${workspaceRoot}/packages/api/out/*"],
        "sourceMaps": true,
    },

Note - you'll need to modify outFiles to include everything you might want to add a breakpoint to. This can be more tedious when in a monorepo and multiple dependent projects.