coverage summary always 100%
See original GitHub issueExpected behavior
should report coverage summary correctly
Actual behavior
always output
Statements : 100% ( 0/0 )
Branches : 100% ( 0/0 )
Functions : 100% ( 0/0 )
Lines : 100% ( 0/0 )
Enviroment Details
- Karma version (output of
karma --version
): 1.1.0 - Relevant part of your
karma.config.js
file
coverageReporter: {
reporters: [
{ type: 'text-summary' }, // always 100%
{ type: 'text-summary', file: 'lcov.txt' } // reported file is correct
]
}
Steps to reproduce the behaviour
1.just run 2. 3.
Issue Analytics
- State:
- Created 7 years ago
- Comments:7 (6 by maintainers)
Top Results From Across the Web
Karma code coverage always shows 100% (0/0) for the tests
Coverage should be 100% if you have (0/0 ). Because this means 0 fails from 0 tests. – Tome Pejoski. Dec 28, 2016...
Read more >When 100% code coverage is not always enough
When 100% code coverage is not always enough ... Even if we had 100% code coverage, this doesn't mean the code is immunue...
Read more >The Case Against 100% Code Coverage - Codecov
In this article, we will discuss instances when reaching 100% code coverage is not worthwhile. Instead, a value around 80% is a much...
Read more >What's the impact of aiming for 100% test coverage? - OddBird
100 % test coverage is a contentious metric! In this piece, Olu explores the impact of pursuing it.
Read more >Jest code coverage report explained - Emma Goto
After you run the coverage command you'll get a summary report that looks like this: ... Jest will report that you have 100%...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
I think i have the same issue. It only occurs with karma 1.1.0, not 1.0.0 or 0.13.x. As the problem seems to be introduced in karma 1.1, i think the issue should be in the karma issue tracker
There seems to be a raise condition. I think karma is collecting the reports too soon. Usually this doesn’t result in an error because the
html
reporter first needs to verify that the directory structure is created (withfs.stats
, see reporter.js). By then, thecollector
is filled. However for Stryker we’re using thein-memory
reporter. That one tries to collect the report immediately which usually fails with karma 1.1.0.If i surround reporter.js L290 with a
setTimeout
the collector is always filled.I have been debugging this issue for hours, but my inside karma knowledge is just too small. Can someone point me in the right direction? Namely: did something in the life cycle of reporting change what could explain this raise condition?
See this build output (with karma 1.1.0): https://travis-ci.org/stryker-mutator/stryker-karma-runner/jobs/140456228
Note: I see in the bug request that the
text-summary
has the same issue, which makes sense as it is also reporting immediately, without the creation of the file system.I’ve implemented a fix, thanks for the research