I'm just beginning to use Jest in my nodejs project. I have several test and all pass, but the last test I just coded is passing but is blocked in two places by Jest with code like this:
/* istanbul ignore next */
cov_19rdmie87d().s[43]++;
debugger;
/* istanbul ignore next */
cov_19rdmie87d().s[53]++;
this debugger;
I have to hit f5 to continue twice while running my tests. How can I remove these debugging statements?
Solution:
Remove debugger statements from your code and any kind of breakpoints from your inspect sources.
Some more Wiki on Debugging in JS
Debugger : If you place a debugger; line in your code, Chrome will automatically stop there when executing. You can even wrap it in conditionals, so it only runs when you need it.
Type debug(item.myFunc) in the console and the script will stop in debug mode when it gets a function call to item.myFunc
When you need to debug JavaScript, Chrome lets you pause when a DOM element changes. You can even monitor its attributes. In Chrome Inspector, right-click on the element and pick a break on setting to use.
For more information, check out this article by raygun on debugging in javascript.
Related
I would like to have collapsible/ expandable objects in the terminal output in VS Code like on the browser console.
Here is an example:
In the debug terminal it works only if I toggle a breakpoint before the end of the program, but otherwise I get the error "No debugger available, can not send 'variables'".
So I'm thinking if the functionality is there, there must be a way to get it even without setting breakpoints every time. Right?
Use console.dir() instead of console.log().
Use this following example, to display all nested objects:
console.dir(yourStuff, { depth: null })
use
"outputCapture": "std"
in launch.json
I like letting mocha -w run in a terminal while I work on test so I get immediate feedback, but I can't always tell from a glance if it's changed or not when the status doesn't change - did it run, or did it get stuck (it's happened)?
I'd like to have a way to append a timestamp to the end of each test run, but ideally only when run in 'watch' mode - if I'm running it manually, of course I know if it ran or not.
For now, I'm appending an asynchronous console log to the last test that runs:
it('description', function () {
// real test parts.should.test.things();
// Trick - schedule the time to be printed to the log - so I can see when it was run last
setTimeout(() => console.log(new Date().toDateString() + " # " + new Date().toTimeString()), 5);
});
Obviously this is ugly and bad for several reasons:
It's manually added to the last test - have to know which that is
It is added every time that test is run, but never others - so if I run a different file or test -> no log; if I run only that test manually -> log
It's just kind of an affront to the purpose of the tests - subverting it to serve my will
I have seen some references to mocha adding a global.it object with the command line args, which could be searched for the '-w' flag, but that is even uglier, and still doesn't solve most of the problems.
Is there some other mocha add-in module which provides this? Or perhaps I've overlooked something in the options? Or perhaps I really shouldn't need this and I'm doing it all wrong to begin with?
Mocha supports root level hooks. If you place an after hook (for example) outside any describe block, it should run at the end of all tests. It won't run only in watch mode, of course, but should otherwise be fit for purpose.
Following this discussion I attempted to debug a mocha test script via the following:
mocha --inspect-brk ./tests/foo.test.js
This does indeed present an inspector URL that I can bind to in Chrome, but the "sources" are populated only with the source of mocha itself, not my code - is there something I need to change to get the inspector to bring up my code and not mocha's?
(I did see a similar question but I'm hoping for an answer that doesn't involve bringing in another dependency like node-inspector.)
Add debugger to one of your tests. When you resume in dev tools, execution will pause in your test code and you can browse your files.
it('should replace a template string', function(){
debugger
expect( Helper.templateString('{{a}}', {a:2}) ).to.equal( '2' )
})
You can also step over _mocha until it loads the files, which is around line 460 in v5.0.4, labeled requires:
// requires
requires.forEach(mod => {
require(mod);
});
After this you can browse your files and set break points. Dev tools will remember the break points for the next run.
I have a codebase where I have quite a number of
debugger;
statements. Sometimes I debug, and I actually just want to skip all of the debugger; statements and continue only to the manually set breakpoints that I have chosen for the debugging session, is there some setting by chance with Node.js to do that?
In other words, I would like to consider the debugger; statements to be long-term placeholders, but for certain debugging sessions I would like to ignore those long-term placeholders.
That can be done with the chrome devtools.
You can do:
node --inspect --debug-brk index.js
that will generate something like this:
chrome-devtools://devtools/remote/serve_file/#60cd6e859b9f557d2312f5bf532f6aec5f284980/inspector.html?experiments=true&v8only=true&ws=localhost:9229/9c2e4f37-4c3a-4477-b8da-2399c5d9819e
Just copy and paste that on chrome.
There is an option to disable/enable all the break points, and chrome will remember all the breakpoints that you set previously.
Please check: --inspect for more info.
A trick I've used in the past is to just use babel to strip out debugger statements:
See:
https://www.npmjs.com/package/babel-plugin-remove-debugger
Quick and dirty way (its for debug so, its fine really) is to stick something like the following script in scripts/debugger.js
require.extensions['.js'] = function(module, filename) {
var content = fs.readFileSync(filename, 'utf8').replace(/debugger/g, [
'(function() {',
' if (__debugger) {',
' debugger;',
' }',
'})',
].join('\n'));
module._compile(content, filename);
};
then start node with node -r ./scripts/debugger
Using a global variable here so that it can be enabled/disabled from the debugger repl or chrome's repl if debugging with --inspect.
Technically require.extensions is deprecated, but it's not going to be removed and it works as intended here.
var express = require('express');
Debugger;
var router = express.Router();
In node debugger, when the control stops at second line, i do this,
debug> repl
Press Ctrl + C to leave debug repl
> express
[Function]
> express.
here, after 'express.', pressing tab for autocomplete doesn't list out Router option but node builtin properties like hasOwnProperty, call, bind... are there.
express.Router
is defined in
`node_modules/express/lib/router/index.js`.
I see, no reason this property may not be part of the express object.
In summary, node debugger autocompletion is not listing all the properties for express object.
This is a side-effect of the fact that express exports a function rather than a standard object. e.g.
module.exports = function(){ ...}
module.exports.Router = Router;
It all comes down to this line in the Node source, which ends up basically saying "if autocompleting a function, treat it like a simple anonymous function", thus it doesn't have any extra properties.
The reason for the roundabout code is because when you run node debug ..., you are actually starting two node processes, with one running your code, and one running the debugger. That means that when you autocomplete, the debugger process must send a message to the process being debugged, asking for information, and then it has to translate that back into something that you can render for autocompletion.
Looking over the node core source, my educated guess would be that this was simply the easiest thing to do. The current architecture of the debugger tries to hide the debugger implementation as much as possible, but that means that the autocompleter doesn't know that it is working on a faked object copy and the debugger doesn't know that we are autocompleting. The downside of this is that it tries to recursively duplicate the whole object before processing the autocomplete, meaning it does a costly recursive operation to then simply discard the result. Unfortunately adding function property recursion makes the autocomplete quite slow from my quick test a minute ago.