test cov

[tj]

write a proper test cov lib

[Raynos]

+1 on this. The main thing missing is easy test coverage that just works.

[podviaznikov]

+1

[dhendo]

+1

[timoxley]

+1

[BryanDonovan]

+1

[ashwinphatak]

Will the test coverage functionality be ported over from expresso, based on jscoverage?

[tj]

nope

[ashwinphatak]

Ok. Is it because of some technical reason (e.g. doesn't play well with mocha) or due to it being very low on the list of priorities?

[tj]

just because jscov is the "lame" way to go about it, we could easily write similar with pure javascript, just need some time

[logicalparadox]

+1 ... were you thinking of writing a separate module to do this or would this be included in mocha? My vote would be a separate module. Either way, please let me know where and how I can contribute :)

[tj]

definitely a separate module

[daaku]

+1 ... https://github.com/chrisdickinson/node-runforcover or something using bunker directly?

[alfredwesterveld]

+1

[chrisdickinson]

let me know if there's anything you'd particularly like to see in runforcover that would make integrating it with mocha easier.

it's a little specific to require hooks at the moment, but could be made more generic if need be.

thanks!
chris

[tj]

@chrisdickinson will do! it'll need to support the client-side as well so I almost think the jscov extra directory approach might be fine

[BryanDonovan]

Are there any examples out there that show how to use runforcover with mocha? I tried it, and got it to work (and it worked well) for a single test at a time, but couldn't figure out how to wrap entire test suites, especially with nested tests.

[fengmk2]

Is there any plan for this feature?

[tj]

there is but I've got a lot of stuff going on so it wont be any time soon

[tj]

sneak preview of what I have so far:

[fengmk2]

wow, nice job, I think we will see coverage.html soon.

[danielkrau]

Why don't you use an existing solution?
I think of coveraje. It works for me (also with tests written for mocha).

[tj]

because this one can look the way I want :p

[jgallen23]

looks awesome! (as always)

[danielkrau]

fork & edit?

[tj]

@danielkrau it's not difficult to just re-do it, that's only an hour or so work from last night

[danielkrau]

@visionmedia oh, ok. if it's that easy...coveraje is clearly not that beautiful, but it works (and now I'm going to investigate your solution)

[BryanDonovan]

Thanks for adding this, TJ. It's working well for me. Had to jump through some hoops since our "lib" is named "src" though. In case anyone else has some trouble, the workaround for me is to have all our tests use a custom require function (which we had anyway, but not it checks if we're running jscov):

var lib_dir = 'src';

var require_src = function(filepath) {
    if (process.env.JSCOV) {
        lib_dir = 'lib-cov';
    }

    var root_dir = path.resolve(__dirname, "../../");
    return require(path.join(root_dir, lib_dir, filepath));
};

// In a test file:a
var foo = require_src('bar/foo');
// instead of
var foo = require('../../src/bar/foo');

And our Makefile sets JSCOV=1 when running 'make test-cov'.

This is pretty hacky though. Am I just not noticing a simpler solution?

[tj]

@BryanDonovan the directory names is not important. All you have to do instrument the lib, in your case something like:

$ jscoverage src src-cov

create an ./index.js file so that you can alter which ./src lib is actually used:

module.exports = process.env.MYLIB_COV
  ? require('./src-cov')
  : require('./src');

That's pretty much it, it's not as transparent as it used to be with node require.paths but it's not all that hacky. In general it is bad-practice to require nested mods though (require('foo/bar/baz') so that may make things a bit more difficult if you're doing that

[BryanDonovan]

Ah, thanks. I'll try that. This application was set up before I came on board, so I just went with what others were doing.

Why is requiring nested mods a bad practice? For us it's not so much nested, it's just an organization structure. Something like:

our_app/src/apps/app_one/model.js
our_app/src/apps/app_two/model.js
our_app/src/common/some_shared_module.js

I.e., we have several "apps" in parallel in a bigger application so they can share common code without having to deal with git submodules, etc.

One thing that I hated at first about node (or our setup) was having to require every little file. But now I kind of like it. It's very explicit what you're requiring. But maybe there's a big downside I've overlooked?

[tj]

yeah it's annoying and nice at the same time haha. It's fine for your own application I guess, but for libraries you should expose things via the single require(), something like require('express').Router vs require('express/router') for example. I guess your hack isn't so bad then for your use-case, I would definitely try and expose models etc via the main module, might help some of the .../.../.././/././/. pain

[BryanDonovan]

Oh, I see what you're saying. Yeah, for a library (and some internal libraries) we use a single require.

[BryanDonovan]

Oh, another question: It seems that if a file is not loaded at all by the test suite, then it doesn't show up in the coverage report. I suppose this would be solved by using an index file that loads all the source code or something, but it seems like that would make some mocking/stubbing difficult. It would be nice if it reported on all files that are in lib-cov, not just the ones that were required by the tests. This may be a limitation of jscoverage though?

[tj]

yeah that's because jscoverage populates the $_jscoverage global with the source etc

[BryanDonovan]

Ok, I figured it was something like that. Thanks for all the help.

[alfredwesterveld]

I was wondering if the native javascript code coverage is abandoned because at post #5 (comment) you said you would try and built that which I think would be awesome, but then again I think it might take significant time.

Is this jscoverage is just a temporary (quick fix)solution, because it is not native?

[tj]

@alfredwesterveld jscov works really well so there's not really a great reason to reinvent it, especially since it's a one-time install. Maybe in the future with esprima but it's not a huge deal

[domenic]

I might be missing something, but we tried to use it on Windows and it wouldn't install. So there's that.

Coveraje works pretty well, and I've also seen node-cover.

[tj]

yeah I guess windows too

[tj]

effectively anything that produces the same result as jscoverage would work just fine with what is existing right now, which isn't too hard but it's not top-priority for me