Could we fully automate ports selection so that there is no need for defining ports?

Yes, it's exactly the second case in the usage section, where no ports configuration is provided and they are chosen automatically. Once process is running in debug mode NodeJS prints debug port, so auto generated port will be sufficient to connect to the process using debugger. Port configuration option is mostly enhancement that will allow to have some fixed debugging configuration in IDE (I'm using "Node.js remote debug" option in WebStorm) that should not be updated each time. I'm currently working on PR, but I'm pretty sure that your implementation will be definitely better.

Regarding implementation I think it should be something like the code below (in testrunner.js before forking the process)

function runOne(opts, callback) {
    ...
    var debug = process.execArgv.reduce(function(prevArg, curArg) {
        return prevArg || curArg.indexOf('--debug') === 0;
    }, false);

    if(debug) {
        process.execArgv.push('--debug-brk=' + freePort);
    }
    ...
}

Inspired by this post on StackOverflow.
To find free port freeport or find-free-port may be used.

P.S.
Thanks a lot for your responsiveness and cooperation! I'm really appreciate this.

After looking on code more deep I realised that cli.js spawns only one child process (spawning multiple child processes is only available via API), thus there is no need in list of ports - only one debugging port is needed. Specifying port is also may be optional since it may be auto generated.

@kof I've submitted PR few minutes ago, please take a look. I'm sure you know how to do it better, but idea remains the same. At least for me it solved the problem with test debugging.

Hi, guys. Just curious, if you are going to complete this enhancement and provide an ability to debug execution of tests by node-qunit?
Thanks.

I believe you can use Node.js CLI options such as --inspect via the NODE_OPTIONS environment variable. For example:

NODE_OPTIONS='--inspect' qunit test/index.js

That will not cover sub processes, but at least it solves the issue of being able to use the qunit command without needin the full path to the js file with the node command.

Also consider using the official QUnit CLI, which might suite your needs: https://qunitjs.com/cli/