Forced Mocha.js as direct script include

[ralf57]

Apparently, the mocha.js script needs to be included as a separate resource. See https://github.com/nathanboktae/mocha-phantomjs-core/blob/master/mocha-phantomjs-core.js#L123 I find this quite limiting since most of the times the JS libs are simply aggregated and served as a single .js file. Also I don't get the rationale.

[nathanboktae]

Why would you need to bundle a test framework with your tests or product code? Some default webpack thing? I concat and minify my product code and run the tests on that, then the bundle as is is what is shipped out.

There are few settings like slow, timeout, etc that must be set before after Mocha loads but before the tests does, as they get replicated per test. This was a change in mocha and broke those settings for mocha-phantomjs 3.x and earlier as it would set them when mochaPhantomJS.run was called, but it was too late.

Currently I am only conditionally exposing initMochaPhantomJS, but I could always expose it and you'll have to explicitly call it before calling any mocha setup functions.

[ralf57]

Hi @nathanboktae and thanks for your reply. In my current setup (not sure it's the best possible, though), I run

mocha-phantomjs http://localhost/test.html

In test.html, I load the test-libs.js (which contains all the vendor libraries only used for testing, including mocha.js) and tests.js (the actual mocha tests code) files. As you see, it's a not so uncommon scenario.

Mocha-phantomjs 3.x works just fine while 4.x doesn't due to the mocha.js single include failure.

[nathanboktae]

I load the test-libs.js (which contains all the vendor libraries only used for testing, including mocha.js)

Why? Most people use npm or bower and just include them. Your scenario is not common.

I explained problems that existed in 3.x and a workaround... Any responses to that?

[ralf57]

Why? Most people use npm or bower and just include them. Your scenario is not common.

I also handle frontend libraries via bower but then use gulp to minify them (I have dozens) in order to speed up loading time. I don't see what's wrong with this approach.

Regarding the 3.x version usage, I simply have this

if (window.mochaPhantomJS) {
    // do the mocha setup load the tests and then
    mochaPhantomJS.run();
}

[nathanboktae]

I use bower and gulp too, but bundling test dependiea with production dependencies make no sense. Tests run locally not over the internet.

You still didn't answer my first question and have repeated yourself thrice. I know how 3.x works.

[ralf57]

Of course, I don't ship testing dependencies out but there are libraries, for instance Moment.js, used both for testing and production. So I end up with libs.js and test-libs.js with only the former being delivered. Sticking to the subject, if it's not possible/easy for mocha-phantomjs to handle such a scenario, I will just pull mocha.js out and call it a day.

[nathanboktae]

So not only are you wasting your time bundling test dependicies, now your stack traces are total garbage as phantomjs doesn't support source maps. Bad idea.

Still I can always expose initMochaPhantomJS so you can call it from the appropriate time in your bundle

[ralf57]

Thanks for the advice. Glad we come up with a solution in the end.