Next release

[serut]

My bad, something is wrong with the default coverage.json file now.
Otherwise, it looks stable so far.

[codecov-io]

Current coverage is 75.96% (diff: 76.01%)

Merging #30 into master will increase coverage by 0.89%

@@             master        #30   diff @@
==========================================
  Files            20         22     +2   
  Lines           658        774   +116   
  Methods           0          0          
  Messages          0          0          
  Branches          0          0          
==========================================
+ Hits            494        588    +94   
- Misses          164        186    +22   
  Partials          0          0          

Powered by Codecov. Last update 7075ff7...9bfcda0

[cgalvarez]

The glob pattern **/.npm/package/node_modules/** is already catched by **/.?*/**, which excludes any hidden folder, but does not cover node_modules folder in a meteor app (in a meteor app, the used NPM modules are installed at node_modules, not .npm/package/node_modules), and that's why I set it up as **/node_modules/**. I'm developing a meteor app with angular2-meteor, and all the NPM packages are saved to node_modules/**, so the current glob pattern presumably will not catch it (not tested yet, I'm focused on meteor package testing right now).

**/web.browser/packages/** is already catched by **/packages/!(local-test_?*.js), except the last one will exclude the compiled & run test file, which it's needed to traverse the tested file(s) through its source map.

Finally, the node_modules exclusion should be done in both, client and server.

[serut]

I released yesterday to have something to discuss, so sorry for regressions. Looks like /home/travis/build/serut/meteor-coverage/packages/local-test:lmieulet:meteor-coverage/server/tests.js is not rewritten correctly and made the error, so it's related to SourceMap algorithm.
I am not super exited to exclude the node_modules entierely, but if that's required, let's do that.

[cgalvarez]

{Install spacejam as a globally available NPM package and execute spacejam test...} OR {install it as a local NPM dev-dependency and execute node_modules/.bin/spacejam test... or node_modules/spacejam/bin/spacejam test... or better, $(meteor npm bin)/spacejam test...}, but not mix both 😉

Otherwise, users will have to add the binaries path to their $PATH environment variable in some way, like export PATH="$PATH:./node_modules/.bin" or export PATH="$PATH:./node_modules/spacejam/bin" to get the package.json script commands working.

[cgalvarez]

Some findings:

1. Executing meteor test-packages --driver-package practicalmeteor:mocha --settings settings.coverage.json tests my package and lmieulet:meteor-coverage, generates my package coverage reports (because of the glob patterns) and makes the HTML report available on localhost:3000/coverage.
2. Executing meteor test-packages ./ --driver-package practicalmeteor:mocha --settings settings.coverage.json tests only my package, doesn't generate report on the output folder, and thus the HTML report on localhost:3000/coverage is empty, which is why I opened HTML report on live meteor package testing is empty #23.

Any idea about what could be happening here?

More on this: I've redirected the output of the server console to text files and made a diff which shows:

• 1. includes all the packages (which is a bit weird, because I execute the command in my package folder; only lmieulet:meteor-coverage and my package are visible because are the only two packages that contain tests).
• Definitely the BIG difference is that 2) stops after echoing MochaRunner.runServerTests: failures: 0, and 1) starts exporting coverage reports right after that same message, which explains why the output folder is empty, but not why this is happening.

[cgalvarez]

If you can start to work from this branch, it will be easier to integrate. For me, it's better if you create a pull request to integrate into serut/dev-1.0.0, I accept the pr and the commit pops here. PR #22 lacks some fix that serut/dev-1.0.0 has, but do as you can.

You're right. I noticed that before reading your answer, and did it that way. Let me know what you think about the algorithm. It applies a lot of changes, but better IMO.

It can be done by creating a new widget displayed by practicalmeteor:mocha on the test page that makes the HTTP calls, otherwise it's not possible.

I apologize if I explained bad. I was wondering how the coverage gets re-calc after rerunning the tests (the coverage-watch feature you mention in the readme.md). When I exec npm run test:packages-coverage-watch, I can see the tests results at localhost:3000 and the coverage HTML report at localhost:3000/coverage. If I make any changes to the package code, the tests are re-run, localhost:3000 gets updated, and looking at the server console logs, after mocha runner has finished its tests the coverage reports start generating. What I would like to know it's exactly that, how the reports start generating automatically when the tests are re-run.

[serut]

looking at the server console logs, after mocha runner has finished its tests the coverage reports start generating. What I would like to know it's exactly that, how the reports start generating automatically when the tests are re-run.

I don't follow you: there is no algorithm that creates reports on watch test ! meteor-coverage doesn't know that tests are done and can't produce reports by itself.

[cgalvarez]

Ok, I'll see what's happening here then. Thank you very much 😉

[cgalvarez]

Don't know when you plan to release v1.0.0, but I've found some more SourceMap issues that already fixed but not commited yet in a new PR, and still investigating the issues you comment on merged PR #33 because I'm facing them right now.

IMO would be desirable to have them all fixed before releasing v1.0.0 😊. Just letting you know about my intentions to fix these 🪲🪲🪲 and their existence. I'm currently working on them.

[serut]

I pushed meteor-coverage-app-exemple with the current branch and it failed a little bit, so I dont plan to release before both meteor-coverage and meteor-coverage-app-exemple are green. Anyway with your pull request all files are a lot better mapped to real files, so again thanks you very much for your awesome work. We can release the next week maybe ?

[cgalvarez]

We can release the next week maybe?

I'm giving my best effort to fix this issue definitely ASAP 😉 , but it's a fact that I can't fix what I don't understand yet 😇 .

so again thanks you very much for your awesome work

Thanks to you. You've made this awesome package. I'm only helping to improve it a bit.

I pushed meteor-coverage-app-exemple with the current branch and it failed a little bit

I tested serut/meteor-coverage-app-exemple for first time. The commands I've run are the same as in .travis.yml:

• meteor npm run coverage-app-unit
• meteor npm run coverage-app-full
• meteor npm run coverage-packages-mocha

I saw some Altered source could not be accessed messages in the console. I suppose that's what you mean with it failed a bit. They are already fixed in the upcoming PR. If the issues are others, please, let me know.

---

Let's go with another issue: if I exec the following commands inside the meteor-coverage folder:

1. spacejam-mocha test-packages ./ --coverage "out_lcovonly out_html": I get all the package files in the HTML report.
2. meteor npm run test:packages-coverage-watch: the HTML report lacks some files.

This is very weird. The difference that surely makes those files missing in the reports is that (1) shows Module load hook: transform [/tmp/meteor-test-run1yxq98/.meteor/local/build/programs/server/packages/lmieulet_meteor-coverage.js in its verbose output, while (2) no. That file is the merged file of the entire package, and its source map contains the references to all the package files, which would be included if that file would be hooked by Istanbul.

Is this what you commented on PR #33? Any idea of what could be happening here?

[cgalvarez]

I've made PR #34 to fix these issues and another PR #4 to meteor-coverage-app-exemple to cover the two specific cases that I was testing with my own package because I forgot to test them in the previous PR. This way we ensure they will always be tested.

[cgalvarez]

Just discovered that there exist a shorten form for meteor test-packages --driver-package practicalmeteor:mocha ... too: meteor-mocha .... 🤘

spacejam-mocha test-packages --coverage out_lcovonly is wrong, it should be spacejam-mocha --coverage out_lcovonly.

According to the spacejam code:

• spacejam-mocha = spacejam test-packages --driver-package=practicalmeteor:mocha-console-runner "$@"
• meteor-mocha = meteor test-packages --driver-package=practicalmeteor:mocha "$@"

The two short forms can only be used when testing packages.

[cgalvarez]

Sorry, moved this comment to its own issue #35 .

[serut]

• Fix remap timeout or replace it by xit to ignore the test
• Edit readme.md with how to use remap
• Remove legacy code inside reporters because now files are merged correctly mapped with real ones
• Edit changelog
• meteor-coverage-app-exemple build ok : 👋

[cgalvarez]

@serut You merged the code of the branch new/remap in my fork. I didn't the PR because I was still testing it against meteor-coverage-app-exemple. The failed CI tests are due to it. I'll take a look at it.

EDIT: I'll start fixing that checklist tomorrow. I faced the timeout before, but it's due to an error, remap is fast.

[HugoHeneault]

Got some ETA for this?

[serut]

Very soon !

[coveralls]

Coverage increased (+0.9%) to 75.969% when pulling 9bfcda0 on dev-1.0.0 into 7075ff7 on master.

[coveralls]

Coverage increased (+3.3%) to 78.356% when pulling 02e02af on dev-1.0.0 into 7075ff7 on master.