Comments (39)
+1 on this. The main thing missing is easy test coverage that just works.
from mocha.
+1
from mocha.
+1
from mocha.
+1
from mocha.
+1
from mocha.
Will the test coverage functionality be ported over from expresso, based on jscoverage?
from mocha.
nope
from mocha.
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?
from mocha.
just because jscov is the "lame" way to go about it, we could easily write similar with pure javascript, just need some time
from mocha.
+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 :)
from mocha.
definitely a separate module
from mocha.
+1 ... https://github.com/chrisdickinson/node-runforcover or something using bunker directly?
from mocha.
+1
from mocha.
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
from mocha.
@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
from mocha.
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.
from mocha.
Is there any plan for this feature?
from mocha.
there is but I've got a lot of stuff going on so it wont be any time soon
from mocha.
sneak preview of what I have so far:
from mocha.
wow, nice job, I think we will see coverage.html
soon.
from mocha.
Why don't you use an existing solution?
I think of coveraje. It works for me (also with tests written for mocha).
from mocha.
because this one can look the way I want :p
from mocha.
looks awesome! (as always)
from mocha.
fork & edit?
from mocha.
@danielkrau it's not difficult to just re-do it, that's only an hour or so work from last night
from mocha.
@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)
from mocha.
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?
from mocha.
@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
from mocha.
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?
from mocha.
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
from mocha.
Oh, I see what you're saying. Yeah, for a library (and some internal libraries) we use a single require.
from mocha.
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?
from mocha.
yeah that's because jscoverage populates the $_jscoverage global with the source etc
from mocha.
Ok, I figured it was something like that. Thanks for all the help.
from mocha.
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?
from mocha.
@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
from mocha.
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.
from mocha.
yeah I guess windows too
from mocha.
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
from mocha.
Related Issues (20)
- 🐛 Bug: mocha does not compatible with node.js test runner HOT 1
- 📝 Docs: Remove Matomo from the website HOT 1
- 🐛 Bug: Failed to run tests with a large tests count HOT 1
- 🛠 Repo: Tests broken on main for xunit after conflicting merge
- 🛠 Repo: Remove `husky` for now HOT 3
- 🛠 Repo: Replace `nps` with ordinary npm scripts
- 🐛 Bug: Audit and fix accessibility for browser reporter
- 🚀 Feature: Unify `--ignore` and `--watch-ignore` and make the patterns recursive
- 🐛 Bug: Unit test cases taking too much time to execute HOT 1
- 🐛 Bug: <short description of the bug>
- `skip` shows "pending" instead of "skipped"
- 🐛 Bug: Test titles not shown for ES dynamic imports
- 🐛 Bug: mocha fails silently on invalid `package.json` section
- Bump chokidar HOT 3
- 🐛 Bug: [email protected] has a performance bug HOT 1
- 🐛 Bug: Error Importing TypeScript Class: Only .js Extension Supported, Not .ts HOT 1
- 🐛 Bug: when using exports interface for tests, there's no file on suites objects HOT 4
- 🚀 Feature: Update glob from 8.1.0 which is no longer supported HOT 1
- 🐛 Bug: Watch + mochaHooks inconsistent state on re-runs
- 🐛 Bug: Hit an error with CJS named exports
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from mocha.