Compatibility with gulp-mocha

[nfriedly]

Hey, I can't seem to get this to load correctly inside of gulp-mocha, I think because my copy of mocha is "hidden" inside of gulp-mocha, so when this one runs require("mocha") it blows up. (If that's the cause, then npm v3.x will fix it, but it's still worth considering for older versions.)

Also, mocha currently reports the wrong error message, I filed mochajs/mocha#1952 to address that.

[nfriedly]

An easy way to configure from within gulp would be nice too ;)

[meaku]

Did you configure xunit-file as reporter in gulp or globally?

[nfriedly]

In gulp, and then I used an env prop to set the filename
On Oct 31, 2015 6:48 AM, "Michael" notifications@github.com wrote:

Did you configure xunit-file as reporter in gulp or globally?

—
Reply to this email directly or view it on GitHub
#19 (comment).

[meaku]

Ok.. i just played with gulp and x-unit and you are right.

var gulp = require('gulp');
var mocha = require('gulp-mocha');
var xunitFileReporter = require('xunit-file');

gulp.task('default', function () {
    return gulp.src('test/myTest.test.js', {read: false})
        // gulp-mocha needs filepaths so you can't have any plugins before it
        .pipe(mocha({reporter: xunitFileReporter}));
        //or reporter: "xunit-file" 
});

xunit-file is installed on the top level so it can't find mocha as it's installed as a dependency of gulp and not a main dependency.

The check mocha does is really error prone at the moment. Thanks for filing mochajs/mocha#1952

The problem is that a reporter should not depend on require("mocha").
We used the default x-unit reporter of mocha and changed the output, so we just copied most of it from https://github.com/mochajs/mocha/blob/master/lib/reporters/xunit.js

The reporter is an internal reporter thus it's ok to rely on a BaseReporter class.
To make things cleaner, the 'xunit-file' reporter should be usable standalone and only access the runner passed by mocha when calling the reporter.

[meaku]

@nfriedly i just started making xunit-file a standalone reporter.
Can you try my branch? https://github.com/peerigon/xunit-file/tree/standalone

If it works, we could do some more cleaning up and publish with gulp support.

[nfriedly]

Yep, that works - it generates the xml output. The top-level tests and time attributes aren't right, but I imagine you're still working on that.

(To clarify, with the xunit reporter I get this:

<testsuite name="Mocha Tests" tests="1" failures="0" errors="0" skipped="0" timestamp="Sat, 31 Oct 2015 12:03:41 GMT" time="0.011">
<testcase classname="ZuulModel #createService()" name="should create pre and route filters" time="0.005"/>
</testsuite>

but with xunit-file I get this in my file:

<testsuite name="Mocha Tests" tests="0" failures="0" errors="0" skipped="0" timestamp="2015-10-31T12:02:50" time="NaN">
<testcase classname="ZuulModel #createService()" name="should create pre and route filters" time="0.005"/>
</testsuite>

FYI, I'm going to be out for a fair part of the weekend, so it might take until Monday for me to get back to you. But it looks like you've got a good handle things. Thank you for doing this, it'll make my life much easier.

[whamBamDev]

Hi,

I've raised mochajs/mocha#1956 on the xunit reporter to get their datetime formats changed.

Though the NaN value for the time is a bit naughty:)

[nfriedly]

Ok, cool. Thanks!

[nfriedly]

BTW, I ended up grabbing https://github.com/juhovh/mocha-jenkins-reporter which did the trick for me + gives handy console output for when running the tests locally. So if you don't want to put a lot more work into this, then maybe just add a note to the readme pointing to that one.

[meaku]

Thanks and sorry for the slow progress, but there is not enough time atm... Will consider adding alternatives to the README.

[ashwinaggarwal]

mocha-casperjs --reporter=./node_modules/xunit-file/lib/xunit-file.js throws error in console.
Error: Cannot find module 'path'

Any idea how this can be resolved?

[tannerbaum]

@leomelzer is this resolved now?

[leomelzer]

@tannerbaum hm, I'm not sure...but I don't think so, as work on @meaku's standalone branch never continued and it seems like a good way to clear this up. However I doubt the specific tooling issue is still relevant (it's been 5 years...). We could also close this as stale. What do you think?