Debugging and intergrated testing with Jasmine on Node


I've been experimenting with this for some time and though I'm yet to come up with anything that I'm happy with, I'm definitely more happy with the solutions I have, compared to running jasmine-node in an outside terminal. So I'm sharing them here for the community benefit, and maybe to get some ideas and help on implementing this using a more solid technology.

Current Working Implementation

A set of instructions for those who want to quickly get started:
You will need any linux with perl for the file search. I'm on osx and I don't know how this would work on windows.

1. Download this gist: I'll refer to it as jas-idea.js
2. .. to anywhere require('jasmine-node') and require('underscore')  would work.
3. Set up a NodeJS debug configuration using the following parameters:

Path to node: path to nodejs executable
Working directory: /path/to/your/project
Path to Node App JS File: /path/to/jas-idea.js
Application Parameters: ./path/to/spec/folder/or/file --autotest

Now launch a debug session and watch your changed specs re-run while triggering breakpoints and displaying clickable failures and exceptions.

--autotest is optional, so are other, original options. Feedback is appreciated.

Caveats and unresolved issues

- I've encountered problems debugging in this way some parts of code containing child_process.exec, having the process exit with a malloc error.
- Each test run clears require.cache but many things remain in memory, for example any file system watches, and the debug session could easily get bloated, needing to be stopped and restarted.

A non-working alternative prototype

The version posted works by clearing require.cache after each test run, but its better to run a separate child process to clear everything, as does the original jasmine-node autotest.js. I have another implementation of jasmine auto test, but, I can't figure out how to connect a new child process to a running remote NodeJS debug configuration. It seems that the process needs to be launched first with the --debug-brk option specified, followed by launching the debug session, but with programmatic launching of processes the opposite order is needed. So if you know anything about this and can help, it could provide for a better system.

Happy bug hunting!


Thanks, I can make it work cleaner and faster if we can get the ability to debug child processes. So please vote for this issue !


We have plans to support jasmine-node in WebStorm 5.0.


That sounds cool!

But I wonder if I'm correct in assuming that you will be implementing the ability to debug child processes then?

I am assuming this because if not, any support for jasmine-node would seem to only be extra cruft inside the IDE and a waste of time for you, considering that one can have a suite that can be debugged and viewed within the IDE with most testing frameworks already, using simple debug configurations. With debuggable child processes one can add an auto-test capability, which is incredibly helpful, but currently unavailable within phpstorm, unless you opt for a hacky solution like one I posted here.


Leo, thanks for your effort.
As you said it's possible to add --debug-brk=<port> argument when launching child process.
When child process is launched, run "NodeJS Remote Debug" configuration and debug session will be attached to the child process.
Unfortunatelly it isn't a good solution and I'm afraid there doesn't exist a good one without fixing .

I hope jasmine-node could be supported in IDE wthout launching child Node.js processes at all.
The only need to launch child Node.js processes is to have clear Node.js context when auto-test option is enabled.

Such "auto-test" feature could be implemented using IDE built-in file watcher that runs concrete Run Configuration after changes.
We implemented "nodeunit" auto-test in such a way and it works (it would be available in WebStorm 5.0).

IMHO auto-test feature is useful only for running tests not for their debugging.


Thanks, Sergey, for yours.

As to your hope that jasmine-node could be launched without child processes, I completely agree, if it is possible to completely clear Node's context between runs in other ways, it would make for a better solution.

Please allow me to explain why I've put so much time implementing debug-able auto-testing. A large collection of spec files may take some time to execute. My current unit test directory takes about 8-15 seconds. A single file takes less than a second. What jasmine-node does, and the script above as well, is it runs the whole suite on launch and then only runs the changed spec files as they do change. Having this functionality coupled with a debugger, you can simply place a breakpoint in the suite that you're working on, and triggering a change, enter a debug session right away, not having to wait for the entire suite to run through. It is a much smoother workflow, in my opinion, than having to create or update a debug configuration each time one wishes to work on a spec file.

Also I wonder if there is a way to access this "concrete Run Configuration" from inside a node script? I've built my own test framework that I'm slowly transferring to, and will eventually need to implement auto-testing for it.


No, there is no way to access any IDE's data from Node script.
If you need to run/debug a single spec quickly, context menu from the editor would be available.
Control flow: after editing spec you would right-click "describe" or "it" function call and select "Run <spec>" (temporary Run Configuration would be created and launched).


Unfortunatelly all unsupported test frameworks will suffer.
I'll investigate .


Now that we are on 5.0 did jasmine-node support ever get added? I can't seem to figure out how to use it.


Yes, you are right. Jasmine-node support wasn't added to 5.0. Hope it' will be done for WebStorm 6.


Now that we're on 7.0, did jasmine-node ever get added?


Please sign in to leave a comment.