search

practicalmeteor / meteor-mocha

Depreciated - Write meteor package tests with mocha and run them in the browser or from the command line with spacejam.
https://atmospherejs.com/practicalmeteor/mocha
Other
41 stars 13 forks source link

Add CodeCoverage Support #39

Open joncursi opened 8 years ago

joncursi commented 8 years ago

I've been unable to wrap the

meteor test --once --driver-package dispatch:mocha-phantomjs --port 3100

command within a codecoverage report, i.e. istanbul. Is there a codecoverage tool that you'd recommend?

./node_modules/.bin/istanbul cover meteor test --once --driver-package dispatch:mocha-phantomjs --port 3100

Tests pass, process exits, no coverage info is collected:

No coverage information was collected, exit without writing coverage information
rvetere commented 8 years ago

Would be great to have a code-coverage solution available - it pushes my motivation to write more unit-tests 😄

rbabayoff commented 8 years ago

That is probably a question to the meteor folks. @tmeasday ?

tmeasday commented 8 years ago

I'm not sure how istanbul works. I can probably comment on possible solutions if people can figure out what the issue with using it is.

serut commented 8 years ago

Let's be clear about meteor coverage !

I'm not sure how istanbul works.

Istanbul can hooks require('vm').runInThisContext (see the .meteor\local\build\programs\server\boot.js#278 file to see the call) to instrument a file and when you execute some code of that file, the coverage report (a global variable) is updated. It's totally possible to get the meteor coverage using istanbul.

By default, Istanbul only instruments the require call and not vm.runInThisContext. So the first issue with your command @joncursi is the missing flag --hook-run-in-context to the istanbul command. However, when you run meteor [whatever], it's not the same process that builds your app and runs your app. So basically, you are running istanbul not on the good entry point.

Another solution is to add a dependency to your project that will hook all future call to require('vm').runInThisContext as soon as that dependency is executed. And I've already created that package : https://github.com/serut/meteor-coverage.

rvetere commented 8 years ago

OMG how could i not find this awesomely looking package "serut/meteor-coverage"...? I was already convinced i'll have to mock trough my entire meteor stack with my webpack.test.js what would have costs month (as i'm not familiar with the entire stack anyways) - so i just started to live with the decision "ok so our super-awesome new stack won't have coverage at all... hmpf..."

i'm not sure yet if this solves all my problems but i'm going full risk and i'm already saying: THANK YOU SO MUCH! 😄

Update: ok i was too fast... in my case it's not helping - well it is still a very interesting package, impressing how it just works out of the box.. but he's not really understanding what's going on in my particular setup - i'm building my entire app inside of meteor with webpack.. he's just showing me the final bundle.js of webpack with 100% coverage what can't truly be...

my "npm run test" executes a custom integrated karma-runner with a custom "webpack.test.js" configuration, pointing him into my stack. as normal in a test-setup - the webpack app has no direct entry-point.. it's more like a basic configuration just offering plugins and loaders - all the files he will actually load will be defined with a "test-bundler.js", a special file only referenced inside of karma.conf.js to define the files karma "see's".

this way i'm achieving to have an entire stand-alone unit-testing level - because i don't want to test meteor itself in my unit-test level -> my view-laver is react and so i'm using enzyme with the awesome shallow/mount/render methods to shallowly/locally and entirely isolated test my components only (and they are running 100x faster as i don't have to startup the full heavy meteor itself to just run my tests).

so, the tutorials for such a setup are saying that you only have to include "istanbul" as a reporter and change your "test-bundler.js" in not just giving out the test-files only but giving the entire stack back (just recursively walk trough your entire app-source) -> so the istanbul coverage will see all the files to build up a coverage and not only test files.

well.. if i do this - i'm ending up having files in there which includes Meteor specific code - and so my webpack build always remains excepting with errors like "don't know this module Meteor.blabla"... i see a way to work-around with giving my webpack-config "externals" for all the separate modules.. but this is not enough - i truly have to mock the objects i define there for the purpose they have, it's not enough to just return an empty dummy... then well, the only thing maybe feasible would be to use a thing like sinon to build entire mock objects for each module and define the entire Meteor stack as "external" modules in my webpack.test.js...

still, a thing that takes too much time for me at the moment and unfortunately, i can't see how such a package like "lmieulet:meteor-coverage"