The README.md gives me the impression that debugging of tests is possible with the --serial option. It looks like this option is designed for debugging ava itself though.
I tried debugging tests in the following way:
ava --initnpm install signal-exitnode_modules/ava/debug.js``` javascript
#!/usr/bin/env node
'use strict';
var onExit = require('signal-exit');
var chalk = require('chalk');
process.send = function (data) {
console.dir(data);
};
onExit(function () {
process.emit('ava-cleanup', true);
});
require('./lib/babel');
```
``` javascript
import test from 'ava';
test(t => {
debugger;
t.same([4, 2], [1, 2]);
});
```
node debug node_modules/ava/debug.js " {\"file\":\"path/to/test.js\",\"failFast\":false,\"serial\":true,\"require\":[]} "When running this via the node debugger (or node inspector) the breakpoint is not triggered, possibly due to the code transformations via babel.
Since ava spawns new processes, debugging cli.js directly is not possible. The new node processes try to listen to the same debug port and thus crash with EADDRINUSE :::5858. By hacking fork.js and adding options['execArgv'] = ['--debug-brk=5860']; I could attach node inspector to this port but it still failed to trigger my breakpoint within the test.
Is there any way to use a debugger for my tests?
What Node.js version are you on?
v5.1.1 (from the Debian experimental repository). Simple debugging works:
$ node debug testdebug.js
< Debugger listening on port 5858
debug> . ok
break in testdebug.js:1
> 1 console.log('1');
2 console.log('2');
3 debugger;
debug> c
< 1
< 2
break in testdebug.js:3
1 console.log('1');
2 console.log('2');
> 3 debugger;
4 console.log('3');
5
debug>
We definitely want to support using the debugger, but not really sure from the top of my head what's preventing it. We'll look into it. Thanks for reporting @hberntsen :)
@jamestalmage might have a better idea.
possibly due to the code transformations via babel.
I thought https://github.com/sindresorhus/ava/blob/df48ce69b841c8b5fb1f522aa435d3a676876078/lib/babel.js#L26-L37 did that for us. // @novemberborn
options['execArgv'] = ['--debug-brk=5860'];
Any downside adding this to AVA?
Since ava spawns new processes, debugging cli.js directly is not possible. The new node processes try to listen to the same debug port and thus crash with EADDRINUSE :::5858
That is going to be additionally problematic since AVA will potentially spawn a number of processes at once if you have multiple test files.
I thought that ... did that for us
I think this is separate from remapping coverage/sourcemaps.
Any downside adding this to AVA?
Only the multiple process issue. Can we detect if the debugger is in use and enforce serial execution of the test files?
I think this is separate from remapping coverage/sourcemaps.
Chrome DevToools use source maps to adjusts breakpoints too, so I just assumed this would do that too.
Can we detect if the debugger is in use and enforce serial execution of the test files?
Maybe, but I think it would be better to be explicit about it. I think it would be worth introducing a --debug flag that activates --serial and other things related to debugging. Thoughts?
I think it would be worth introducing a --debug flag that activates --serial and other things related to debugging
+1!
We, JetBrains, cannot support debug AVA tests without changes on your side. I will send you pull request next week.
General information — https://intellij-support.jetbrains.com/hc/en-us/community/posts/206193339-Debugging-node-child-processes?page=1#community_comment_206895729
My solution — https://github.com/sindresorhus/ava/compare/master...develar:debug?expand=1 (not yet reviewed by my experienced college).
Run configuration —

Please note — babel debug in JetBrains IDE is broken in node 5.x, I use my custom build of node 5.x (https://github.com/nodejs/node/pull/4231).
Another problem on AVA side: CachingPrecompiler produces source map, but... debug doesn't work in any case because generated source file doesn't contain sourceMappingURL AVA CachingPrecompiler must add sourceMappingURL explicitly.
So, IDE cannot map source file to transpired because no sourceMappingURL. And breakpoints don't work correctly.
Yes, it is very strange that babel does so, I found related issue — https://github.com/babel/grunt-babel/pull/13
This change will be also in my pull request. For now, you can set both. Do you have any reasons to produce external source maps instead of inline?
Please note again — babel debug in JetBrains IDE is broken in node 5.x, I use my custom build of node 5.x (nodejs/node#4231). Also, to speed up, enable lazy compilation — https://github.com/nodejs/node/issues/877#issuecomment-75248842
After set sourceMaps to both, don't forget to detele cache (node_modules/.cache/ava) to apply change.
I'd love to see an addition to the readme on how to use the debugger for new users. :)
Another problem on AVA side: CachingPrecompiler produces source map, but... debug doesn't work in any case because generated source file doesn't contain sourceMappingURL AVA CachingPrecompiler must add sourceMappingURL explicitly.
@develar this was resolved in #662.
The issue is still open - does it mean that it's still impossible to debug AVA tests in IDEA or Webstorm ?
@azakordonets or VS Code?
@JimmyBoh i prefer products from Intellij :)
@JimmyBoh Only WebStorm currently provides the best AVA debug. https://github.com/avajs/ava/pull/874#issuecomment-227066303
@azakordonets Please see https://github.com/avajs/ava/pull/874 I hope it will be accepted soon.
@develar Thanks a lot :) I've subscribed for that issue
Most helpful comment
I'd love to see an addition to the readme on how to use the debugger for new users. :)