Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Include uncovered files with zero coverage #29

Merged
merged 2 commits into from
Jul 6, 2015

Conversation

dragn
Copy link
Contributor

@dragn dragn commented May 12, 2015

Files that are not covered by specs should, obviously, be included in statistics with zero coverage.

@blond
Copy link
Member

blond commented May 14, 2015

/cc @SevInf

@levonet levonet added the review label Jun 2, 2015
@blond
Copy link
Member

blond commented Jun 16, 2015

@dragn Hi! Sorry for the long wait, I was hoping that @SevInf will help with review this PR.

Could you give a real example with uncovered files?

@blond blond added ready and removed review labels Jun 16, 2015
@dragn
Copy link
Contributor Author

dragn commented Jun 17, 2015

Hi.
(I've added a minor fix that passes root path to istanbul matcher).
About the example... I would add a block with uncovered code to the existing "silly" example, but the thing is: current setup does not use correct path during istrumentation.
You can see here that borschik-tech-istanbul uses current process' working directory, which does not correspond to the root context of "silly" example.
Anyway, here is my attempt to add a block with uncovered code to "silly" example: https://github.com/dragn/enb-bem-specs/tree/example
But the report generated by istanbul looks as follows:

> node_modules/.bin/istanbul report text --include examples/silly/coverage.json
--------------------------------|-----------|-----------|-----------|-----------|
File                            |   % Stmts |% Branches |   % Funcs |   % Lines |
--------------------------------|-----------|-----------|-----------|-----------|
   blocks/block/                |         0 |       100 |         0 |         0 |
      block.js                  |         0 |       100 |         0 |         0 |
   blocks/uncovered/            |         0 |       100 |         0 |         0 |
      uncovered.js              |         0 |       100 |         0 |         0 |
   examples/silly/blocks/block/ |     33.33 |       100 |         0 |     33.33 |
      block.js                  |     33.33 |       100 |         0 |     33.33 |
--------------------------------|-----------|-----------|-----------|-----------|
All files                       |     11.11 |       100 |         0 |     11.11 |
--------------------------------|-----------|-----------|-----------|-----------|

See, what I'm talking about? Paths, instrumented by borschik, should be relative to where coverage,json is, but they are not.
On the other hand, everything is fine, when block directories are located at the root of the project.
BTW, we are successfully using my setup for our project for a few months now (not open-sourced).

@blond blond added review and removed ready labels Jun 17, 2015
@blond
Copy link
Member

blond commented Jun 20, 2015

Thanks for the detailed description of the problem!

I do not like that this strategy (include uncovered files) is not native for istanbul. It is more like unit-coverage. But I understand that it is very useful for BEM.

I propose to solve this problem differently.

At this point we have all the js files.

We can build a dummy coverage.json with zero coverage for all blocks before run tests. And after starting tests this file will be overwritten.

@dragn, What do you think?

@blond blond added ready and removed review labels Jun 20, 2015
@blond
Copy link
Member

blond commented Jun 30, 2015

@dragn, ping.

@dragn
Copy link
Contributor Author

dragn commented Jun 30, 2015

@blond, well I've tried to implement the approach you were talking about, but it did not make it simpler. If we write the coverage.json with all files with zero-coverage in plugin.js, we still need to read that in runner.js and merge it with the output of test runs.
As it's implemented now, we take the list of all sources, exclude those already covered by specs, and put them in the resulted data with zero coverage. That means that at this step we need to know which files are already covered.
I think that current implementation is okay. (readability is so-so, but istanbul's API is not the best out there...)

@blond
Copy link
Member

blond commented Jul 2, 2015

@dragn ok, I agree ;)

I created Pull Request to borschik-tech-istanbul with root option: borschik/borschik-tech-istanbul#4.

After it change will appear in borschik-tech-istanbul then we can correct the error found in your PR.

@blond blond added ready and removed review labels Jul 2, 2015
blond added a commit that referenced this pull request Jul 6, 2015
Include uncovered files with zero coverage
@blond blond merged commit b3431f9 into enb:master Jul 6, 2015
@blond blond removed the ready label Jul 6, 2015
@blond
Copy link
Member

blond commented Jul 6, 2015

I fixed bug with root in b3431f9...3c44b09

-------------------|-----------|-----------|-----------|-----------|
File               |   % Stmts |% Branches |   % Funcs |   % Lines |
-------------------|-----------|-----------|-----------|-----------|
   block/          |     33.33 |       100 |         0 |     33.33 |
      block.js     |     33.33 |       100 |         0 |     33.33 |
   uncovered/      |         0 |       100 |         0 |         0 |
      uncovered.js |         0 |       100 |         0 |         0 |
-------------------|-----------|-----------|-----------|-----------|
All files          |     16.67 |       100 |         0 |     16.67 |
-------------------|-----------|-----------|-----------|-----------|

@dragn
Copy link
Contributor Author

dragn commented Jul 7, 2015

Awesome! Thanks!

@blond blond modified the milestone: 0.5.7 Jul 7, 2015
@blond
Copy link
Member

blond commented Jul 7, 2015

Fixed in v0.5.7.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants