I have recently discovered the magic of debugging Node applications with ndb. (You should really check it out, if you've never seen it.)
For our non-e2e integration tests (which use jasmine) I was easily able to debug the test code simply by substituting ndb for node.
ndb node_modules/jasmine/bin/jasmine.js --config=jasmine.json
When I do the same for protractor, the debugger comes up, but the tests don't begin. For example, the following fails:
ndb node_modules/protractor/bin/protractor protractor.conf.ts --suite smoke
Any clues? (I have a suspicion that it has to do with the Typescript transpilation that happens, but I have no evidence hard evidence.)
I solved my own problem by more trial-and-error. I do not understand why this makes a difference, but the following variation on the ndb command worked:
ndb node node_modules/protractor/bin/protractor protractor.conf.ts --suite smoke
According to ndb --help, ndb provides several variations on how to kick off debug sessions. Like I said, I'm not sure why the ndb node flavor worked while straight ndb failed.
Related
I'm having issues with memory leaks coming from running my test suites with Jest where memory usage keeps growing with each suite.
After searching through the net, I've found that this could be related to a garbage-collector behaviour, and multiple Github threads suggest running this command:
node --expose-gc ./node_modules/jest/bin/jest.js --coverage --runInBand --logHeapUsage
The issue is that my project uses React (with CRA not ejected) and Typescript, so whenever I run this script it throws a Syntax error because of Typescript.
I've tried installing ts-jest library but it does not work. It may be related, but running the ts-jest setup init complains about already having a configuration due to CRA.
I've been searching and I have not found anything, since all related threads are about the known memory leaks Jest has, but none explain how to execute the node command with the expose-gc in a project with React and Typescript.
Is there any way I can expose the GC to the Jest script used by CRA so I can keep using the same configuration as until now?
Otherwise, how can I execute the node --expose-gc jest parsing my files so that it does not throw an error?
I'd also need to use the --inspect-brk to see where the leak comes from, so even if the --detect-leaks works, I still need to find a way to execute my Jest config from node command.
Thank you!
After reviewing the documentation from Jest, I've seen this section which suggests to run the debug configuration in VS Code calling react-scripts. After playing a little bit with it, this is the command that got it working:
node --inspect-brk node_modules/react-scripts/scripts/test.js --no-cache --env=jsdom --runInBand
As you can see, you have to call the test.js file inside react-scripts directly, and then you can send all the arguments you want to Jest, as you'd normally do when running tests directly from the terminal of your project.
If you execute this script:
node --inspect-brk node_modules/react-scripts/bin/react-scripts.js test --no-cache --env=jsdom --runInBand
You will be able to attach to the node debugger, but you won't be able to set debugger stops in your test files, as it will attach to the main process, which is react-scripts (and not the test script itself).
Hope this might help someone in a future!
I use mocha to run my unit tests, and often use npm test in order to run it. My package.json contains these script definitions:
"pretest": "NODE_ENV=test node migrate all",
"test": "DEBUG= NODE_ENV=test mocha --recursive",
If I run either one of these commands directly in my shell (i.e. not going through npm) they execute fine (790 tests takes about 2m to run, the migration script is done in under 1s). The processes also exit cleanly.
If, however, I run these via npm test, everything runs in exactly the same way but the process doesn't exit (I have to manually cancel it with ^c).
I can't work out how to debug exactly what is going on here in order to work out why the process isn't exiting.
It's worth noting that if I test a subdirectory (npm test ./test/queue) which does not interact at all with the database, then the process exits fine. These tests do, however, interact with an AMQP broker so there is some activity over sockets. This suggests to me that the database connection is causing the problem. I am using knex to connect to a postgres9.6 server. This also suggests that the pretest script is not the problem. If I try to run a suite of tests which do interact with the database, the process never exits (so presumably the open sockets are preventing it from doing so, but why this should only happen in the case of npm test rather than direct execution is beyond me).
Extra info:
node version: 8.7.0
mocha version: 4.0.1
npm version: 5.6.0
knex version: 0.14.0
I am using async/await in my codebase
I was mistaken in thinking this to be an npm problem. Rather, when I was running mocha in my shell it was using the globally installed mocha, which is of a different version to the locally installed one. Running with this version causes the same hanging issue.
This change in behaviour appears to be coming from this issue, which is described thus in the changelog:
By default, Mocha will no longer force the process to exit once all tests complete. This means any test code (or code under test) which would normally prevent node from exiting will do so when run in Mocha. Supply the --exit flag to revert to pre-v4.0.0 behavior (#ScottFreeCode, #boneskull)
Does anyone know how to debug a less plugin when using node to compile? So that I would be able to see the value of console.log() within custom less functions.
I am also using gulp-less. I have tried to run the gulp this way:
node --inspect --debug-brk /usr/local/bin/gulp compilecss
This ran the gulp task but I don't see any console from within the function inside the javascript #plugin.
The above mentioned method worked, the issue was that the plugin wasn't set up correctly. For those who were in my shoes this is what worked:
Follow the instructions on this answer for getting the inspector in the gulp task.
enter link description here
Then if your plugin is installed you should see logs in the console from the less custom plugin or it's functions.
I have created a jhipster module (yeoman generator) following steps from [1] and I would have loved to be able to debug the node.js code from the generator at the moment when it is being used in a jhipster app. I found tool at [2] but it acts as if the code from the generator does not get to be run.
Detailed explanation:
I have created the jhipster module generator-jhipster-entity-replacer.
I created a project jhipster-test-proj in whom I invoke
the generator.
yo jhipster-entity-replacer
This is the moment where I would like to see that my breakpoints from generator-jhipster-entity-replacer node.js code are toggled, but nothing happens.
May someone help me with detailed explanation?
I might have been a little blury in explanations due to the fact that I have moreover a stronger Java background then Javascript related one. If someone can help me, but needs more information, please ask.
[1] https://jhipster.github.io/modules/creating-a-module/
[2] https://github.com/node-inspector/node-inspector
Update:
I' ve managed to debug with the command from Pierre Besson's link:
node --debug <path to yo cli.js> <generator> [arguments]
in my case:
node --debug C:\Users\PowerUser\AppData\Local\Yarn\config\global\node_modules\yo\lib\cli.js jhipster-entity-replacer
Even though, I do not recommend this approach. It is a command line debugger with a limited set of instructions, but is still a doable thing.
What i recommend, is this one, a DevTools version for node.js:
https://github.com/node-inspector/node-inspector
I've ran it with the command:
node-debug C:\Users\PowerUser\AppData\Local\Yarn\config\global\node_modules\yo\lib\cli.js jhipster-entity-replacer
Note:
I had to manually delete .yo-rc.json from my generator because otherwise it would not have worked (i had an error like "Just found a .yo-rc.json in a parent directory.", and then it would stop).
when running yo <generator
behind, it is actually running node <path-to-cli.js> <generator> [this is why debugging with node inspector with that command is ok]
I am using mocha to test my code. I am using node inspector to debug my code.
bash
mocha test/test.* --debug-brk
This works but not so well. It stops at the first line of code in mocha. I want it to stop it at my code. I tried using the 'debugger' key word to make a manual breakpoint but some how it does not stop there.
Try placing a breakpoint at the bottom of the mocha library per this issue. For some reason that allows debugger statements in your modules to pause the node debugger.
However it doesn't seem to stop at debugger statements in the spec itself. I have a SO question highlighting that problem.
I was on the latest node version, using the node-debug command (to launch node-inspector and having the same issues you were. Here's what I'm rolling with currently:
Using the following versions:
node: 0.11.13 (I downgraded from latest) <-- I specifically had to use this one
mocha: 2.2.1 <-- might work with any
node-inspector: 0.9.2 <-- might work with any
Start your tests using the following command:
node-debug _mocha test/unit-tests.js
Navigate to your test file and start putting in breakpoints, then hit run. I usually put one up by the 'requires' of my test file, and several within my 'it' functions.
Hope that helps, and that one day this kind of thing will just work :P
Got the idea to downgrade node from here:
https://www.bountysource.com/issues/7978672-script-is-resumed-as-soon-as-node-inspector-is-loaded
And the command from here:
https://github.com/node-inspector/node-inspector#how-do-i-debug-mocha-unit-tests