mocha.run not re-added if testReadyCallback provided

[shortstuffsushi]

In the Mocha adapter, there is a block that hijacks the mocha.run

mocha.run = function (finishCallback) {
  oldCallback = finishCallback;
  console.log("waiting for blanket...");
};

Later, in the beforeStartTestRunner function, it checks if a testReadyCallback was provided. If so, it executes that callback, otherwise it calls the default callback, which can replace mocha.run, but only if existingRequireJS is true.

I'll admit that I'm not entirely sure why the existingRequireJS is relevant to whether or not mocha.run is un-hijacked, but it seems like it should be added back at some point regardless. Is there something I'm misunderstanding?

[alex-seville]

Most of that code is a hacky workaround to the fact that the Mocha runner can't be deferred initialized (as with RequireJS).

Having mocha accept this PR would help (https://github.com/visionmedia/mocha/pull/1124).

[shortstuffsushi]

So will this just need to wait on the result of that then?

[alex-seville]

The current master shows this:

https://github.com/alex-seville/blanket/blob/master/src/adapters/mocha-blanket.js#L62

Basically, the mocha.run gets reset either way, BUT if requirejs ISN'T being used it will also apply the callback passed to mocha.run originally (I forget why requirejs is special in this regard).

[shortstuffsushi]

You know, I did actually miss that it was always getting reset -- read it more of and if/else.

That does actually present another problem, though. When blanket finishes loading, it immediately executes mocha.run. In some cases (in our case) we would prefer to choose when that runs (we have to wait on another load to finish).

Where you replace the mocha.run, you are catching calls to mocha.run, but you aren't checking whether it was ever run. It would probably make sense to conditional execute the mocha.run if that was override was called rather than just executing it every time.

[ahamid]

Edit: well, I upgraded gulp-mocha-phantomjs (^0.10.1) and everything seems to work out of the box so my comment is probably no longer relevant.

Blanket does not proxy Mocha events which can be problematic. I noticed this when using blanket with PhantomJS which relies on run() returning a truthy object on which a listener for the 'end' event can be registered. This was my workaround. I think it would be fairly easy to update Blanket's overridden run with this best effort at maintaining listeners. I explicitly register the testReadyCallback due to #551. Not ideal, but it appears to work for my circumstance.