Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

mocha.run not re-added if testReadyCallback provided #377

Open
shortstuffsushi opened this issue Feb 4, 2014 · 5 comments
Open

mocha.run not re-added if testReadyCallback provided #377

shortstuffsushi opened this issue Feb 4, 2014 · 5 comments

Comments

@shortstuffsushi
Copy link

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
Copy link
Owner

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 (mochajs/mocha#1124).

@shortstuffsushi
Copy link
Author

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

@alex-seville
Copy link
Owner

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
Copy link
Author

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
Copy link
Contributor

ahamid commented Jan 25, 2016

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants