canonical way to debug?

[boneskull]

I couldn't figure this out. Passing the debug flag will open the inspector, but I don't have a chance to set breakpoints, because the bundle is not yet loaded.

The only way I can debug is if I insert a debugger statement in my code.

[mantoni]

Hm, yes. I remember that it was tricky to get it to run at a all with phantomjs. I didn't manage to have the bundle loaded at that time because that would already run the tests while your browser is opening. It's currently only possible with debugger statements and the timestamp based polling until the webkit debugger is connected. We would have to decouple loading the bundle from running the tests somehow.

[boneskull]

I bet mocha's --delay flag could be used to do this, though it would conflict with any other usage. I'm not in front of a computer; is mocha run in phantomjs itself, with a console reporter?

[boneskull]

I suppose you could also use a transform to just wrap everything in a function, then call it when ready

[mantoni]

Mocha is run in phantomjs with a console reporter. Go ahead and experiment. I'll happily merge anything that improves the debugging experience.

[boneskull]

I have the following debuggify.js:

var through = require('through2');

module.exports = function (b, opts) {

  function apply() {
    var firstChunk = false;
    b.pipeline.get('wrap').push(through(function (chunk, enc, next) {
      if (!firstChunk) {
        this.push('window.mochify = function() {\n');
        firstChunk = true;
      }
      next();
    }, function(next) {
      this.push('\n};\n');
      next();
    }));
  }

  apply();
  b.on('reset', apply);
}

If opts.debug is truthy (and opts.node is falsy?) we'll use this as a plugin (assuming it works as-is). When ready, we will call mochify().

I need some direction from here:

• We need to hand off the Browserify output to Mocaccino, so the bundle is loaded immediately, but I'm unsure where that needs to happen, or what needs to be torn out of Mocaccino, if anything. I don't understand all this brout stuff.
• When the debugger statement is reached (I'm not sure which module puts it there), the user will then have a chance to set more breakpoints within the bundle. It'd be especially nice if the user could just work with source maps here, instead of digging through the bundle.
• In mocaccino, we need to change the setup-browser module (I think) to call mochify() after the user continues from the debugger statement.

[boneskull]

also not sure of the impact on instrumentation here, if any. to me, losing coverage functionality while debugging is an acceptable tradeoff.

[mantoni]

Wow, cool. Ok, so first of all, I have to explain what brout does: It makes the process.stdout/err streams available in browsers and allows to listen for process.exit() calls as an event. The default implementation of process.exit() in Browserify wasn't there and I think it's now an empty stub. Usually that's fine, but with unit testing it's nicer to know when a script thinks it's done. This gets used in phantomic and it's a Mocha independent approach. But it's opt in. By default, phantomic will try to figure out if a script is done by some timing measurements, which is far less reliable.

The debugger statement is placed there by phantomic too. In fact, the hole debugging thing is implemented there. I'm wondering if we could use your idea to wrap the whole script in a function, load the bundle and invoke the script after the debugger statement in phantomic? I see it as a "pipe this script into a browser" machine and naturally the place where the debugging is controlled. That way, mocaccino and even mochify don't have to know anything about it.

What do you think?

[kolodny]

I have this as an npm script "debug-tests": "mochify --R spec --consolify output.html && open output.html",

[mantoni]

Is this still relevant?

[mantoni]

There will finally be a better solution for this with the move to headless chrome: #161

[mantoni]

Mochify v5.0.0 released. Place a debugger statement somewhere and run mochify --debug 🎉