Add ability to set MOCHA_GLOBAL_TIMEOUT, without success.

[workflow]

FIXME: Looks like mochaInstance.options.timeout does not pass the timeout to mocha.

Related to practicalmeteor/meteor-mocha-core#9?

[aldeed]

Overall looks good, but see my comment about the default

[aldeed]

I don't think there should be a 2000 default here. Any reason not to just let this be undefined and let the mocha default apply?

[aldeed]

It's possible that setting mochaInstance.options.timeout does not actually work on the server. The server code is a bit different from client. You'd have to see where the value is stored by digging into the code in the mocha repo

[workflow]

@aldeed Totally agree on the default, thx for catching that.

For some reason that I haven't figured out yet, setting the timeout doesn't work via mochaInstance.options (nor directly on the mochaInstance object itself) on the already instantiated mochaInstance, but instead only during the Mocha instance creation here.

Any ideas why?

---

Given those circumstances, I see two ways to fix it, happy to have a shot at option B) if you feel like it's cleaner:

A) Merge practicalmeteor/meteor-mocha-core#9 and document the choice of supported "pass-thru" environment variable name here in meteor-mocha

B) Instantiate Mocha in meteor-mocha instead of meteor-mocha-core, and wrap it through setupGlobals() there. Or, even better, export a PatchedMocha subclass from meteor-mocha-core, that already plays nice with fibers and can be instantiated from meteor-mocha-core.

Any better ideas?

[SimonSimCity]

@aldeed would this be fixed both for server and for client tests by resolving practicalmeteor/meteor-mocha-core#9?

[aldeed]

I suggest doing a new version of that PR against the meteortesting fork and then option A. Not sure if that will fix, and it might be different now with newer mocha, too.

[SimonSimCity]

Fixed by setting the option in https://github.com/meteortesting/meteor-mocha-core. I've added your text to the readme though 😉