Ok, naive question here, but I am somewhat new to nodejs. I am writing a test script using jasmine. There seems to be a bug in my code, so I put "debugger" in one of the lines and jasmine is not stopping for some reason. I know it's getting to the code too, because I put a console.print command and it displays that line.
Is there something incredibly simple that I'm missing? Can't I set a breakpoint in the javascript code and get into a REPL somehow?
You probably run your Jasmine Tests like this:
$ jasmine myTest.js
Or like this:
$ ./node_modules/jasmine/bin/jasmine.js myTest.js
If you want to test node application you have many options, and as you know, jasmine is nodejs code, so you can run it in debug mode, and will run your test, so if you have debugger; in your code it will stop there.
Here are 3 simple ways to debug nodejs applications. Node.js Debug Options
You can use the first one, the build in debugger in nodejs.
Run this command:
$ node debug jasmine myTest.js
Or
$ node debug ./node_modules/jasmine/bin/jasmine.js myTest.js
Then you can press C button + Enter to continue to your debugger; brackpoint in your code...
Related
I've been trying to use Nuclide/Atom to launch and debug a unit test that uses Babel and ES6+ code. The launch config looks like this:
Node runs the unit test as if I had run it from the command-line, and does not stop at my breakpoints. If I use the same invocation at the command-line with --inspect-brk I can debug correctly (with sourcemaps) from the chrome-devtools url in Chrome. Is there a way to make this work? I can't really "attach" since the unit tests are, and should be, a straight-shot script execution.
Nuclide currently does not support the new v8 Inspector protocol for debugging. You will need to use --debug flag to debug with Nuclide. Note, however, that the old debugger protocol has been removed from Node.js starting with Node.js 8.0.
PS. You can attach to a running Node.js process with Nuclide debugger just fine - just start your tests with node --debug --debug-brk ... and then attach the debugger from Nuclide. The test process will be stopped at first line, allowing you to resume execution at your own convenience.
I am trying to debug sls invoke local.
My setup:
However I keep getting:
/Users/nikos/.nvm/versions/node/v6.9.1/bin/node --debug-brk=63417 --expose_debug_as=v8debug /Users/nikos/.nvm/versions/node/v6.9.1/bin/serverless invoke local -f createTodo
Debugger listening on [::]:63417
Process finished with exit code 130 (interrupted by signal 2: SIGINT)
OK, I've figured out how to do this with real Chrome Devtools with the excellent node --inspect. This is much better than node inspector because it uses the latest built in chrome devtools. (more info on node inspect)
node --debug-brk --inspect $(which serverless) invoke local -f myfunctionname
I ran that but my function wasn't loaded yet (probably some lazy loading in the serverless code). So I added a debugger to the top line of my function and everything seems to be working great.
In my case I also needed some test data, so I passed that through like this.
node --debug-brk --inspect $(which serverless) invoke local -f postprocess -d '{"Records":[{"eventVersion":"2.0","eventSource":"aws:s3","awsRegion":"us-east-1","eventTime":"2017-06-17T05:08:29.598Z","eventName":"ObjectCreated:Put","userIdentity":{"principalId":"ALS78N87ZDYNW"},"requestParameters":{"sourceIPAddress":"52.119.114.78"},"responseElements":{"x-amz-request-id":"2EB4FAD5892EC247","x-amz-id-2":"nVLasIYsWvWm7xwONiTB6z7L8oXKkvPOb9FntOYoG/kKS+PuWwbMJ1xM7n/C1X3NJh5FUCj4aEM="},"s3":{"s3SchemaVersion":"1.0","configurationId":"3c3b2a71-b639-4116-b246-08dcacd0c7d6","bucket":{"name":"simmer-uploads-test","ownerIdentity":{"principalId":"ALS78N87ZDYNW"},"arn":"arn:aws:s3:::simmer-uploads-test"},"object":{"key":"example+%285%29.zip","size":4757597,"eTag":"9aa90579ee4e8152e6dfa60258754a83","sequencer":"005944B94AD9307261"}}}]}'
I am working on a Mac, and I heard there might be some problems with $(which serverless) on windows. But someone give it a shot and let me know.
I was able to setup my PHPStorm debugger configuration in a way that now I can step through my functions locally (using serverless-offline plugin).
I am triggering functions via http requests using Postman.
See below steps to achieve this:
1.
2.
3.
4.
I've gotten this to work in IntelliJ, so it should work in Webstorm too. You will need the serverless-offline plugin (https://github.com/dherault/serverless-offline)
In your Run Configuration, change your Application parameters to:
offline -s dev
and add the environment variable SLS_DEBUG=*
serverless-offline will start a server that the IntelliJ Node debugger can hook into.
Use this, it emulates lambda and serverless:
https://github.com/dherault/serverless-offline#debug-process
Mocha has the option to run tests with mocha debug, just like node debug, allowing debug within a REPL console.
How can I do REPL debug with Hapi Lab?
I just have to run node debug node_modules/.bin/lab *.js, just like #matt-harrison said.
The only tip is: Do not use coverage when debugging, since the coverage will change the original code and make debug difficult.
I am using webstorm 10.0.2 and have used the bangular yeoman template to generate a project. I can run the gulp commands via the gulp window, and I can set a breakpoint in the gulpfile.js and it will hit it, but I can't seem to get it to hit a breakpoint in my server.js
It looks to me like the gulp file is launching another instance of node and thus when you do "debug" from webstorm you are just debugging the gulp.
I also tried with another project using yo hottowel but get the same thing - I am unable to debug the actual application through webstorm.
Can anybody tell me how to configure webstorm so that I can debug the actual server side node code but still use the gulp build tool?
I contacted JetBrains support back in May 2015 and their response was:
It seems this cannot be done quickly. In short, the problem is that serve-dev task starts new process (nodemon) that takes app.js
There is no workaround how to debug such spawned processes right now. We would really appreciate if you'll submit a feature request about it in our YouTrack: https://youtrack.jetbrains.com/issues/WEB
The only way you can try to avoid it - try to create a separate task that will run app.js directly without nodemon process and debug this task instead.
It seems the best option is to use https://www.npmjs.com/package/gulp-node-inspector
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