Repository navigation
Closed
Labels
P1Impacts a large percentage of users; if a workaround exists it is partial or overly painfulImpacts a large percentage of users; if a workaround exists it is partial or overly painfularea: @angular-devkit/build-angularfreq3: highseverity5: regressiontype: bug/fix
Milestone
Description
Bug Report or Feature Request (mark with an x)
- [ X ] bug report -> please search issues before submitting
- [ ] feature request
Command (mark with an x)
- [ ] new
- [ ] build
- [ ] serve
- [ X ] test
- [ ] e2e
- [ ] generate
- [ ] add
- [ ] update
- [ ] lint
- [ ] xi18n
- [ ] run
- [ ] config
- [ ] help
- [ ] version
- [ ] doc
Versions
OS: macOS Sierra
Node: v8.9.4
NPM: 6.2.0
Ng Version:
Angular CLI: 6.1.0
Node: 8.9.4
OS: darwin x64
Angular: 6.1.0
... animations, cli, common, compiler, compiler-cli, core, forms
... http, language-service, platform-browser
... platform-browser-dynamic, router
Package Version
-----------------------------------------------------------
@angular-devkit/architect 0.7.0
@angular-devkit/build-angular 0.7.0
@angular-devkit/build-optimizer 0.7.0
@angular-devkit/build-webpack 0.7.0
@angular-devkit/core 0.7.0
@angular-devkit/schematics 0.7.0
@angular/cdk 6.4.1
@angular/flex-layout 6.0.0-beta.16
@angular/material 6.4.1
@ngtools/webpack 6.1.0
@schematics/angular 0.7.0
@schematics/update 0.7.0
rxjs 6.2.2
typescript 2.9.2
webpack 4.9.2
Repro steps
Run ng test --code-coverage
Notice that things like import statements are counted as if else branches.

The log given by the failure
No log file
Desired functionality
I expect to see things like import statements and decorator metadata to not be marked as if else branches in the code coverage report.
Mention any other details that might be useful
Reacted by Stewan Silva, Wilson Kurniawan, Kevin Bosman, Álister Lopes Ferreira, Michael Parry, Justin Pierce, alexw10, 卡色, Holger Persch, thecp and 28 more
Metadata
Metadata
Assignees
Labels
P1Impacts a large percentage of users; if a workaround exists it is partial or overly painfulImpacts a large percentage of users; if a workaround exists it is partial or overly painfularea: @angular-devkit/build-angularfreq3: highseverity5: regressiontype: bug/fix
Activity
wkurniawan07 commentedon Jul 27, 2018
Not providing any solution here, but the problem is likely to be in Devkit 0.7 instead of CLI 6.1.
dimitriy-k commentedon Jul 27, 2018
same issue after upgrade to 6.1.1. coverage dropped from 100%
Statements : 98.13% ( 3667/3737 )
Functions : 99.47% ( 752/756 )
kevinbosman commentedon Jul 28, 2018
Had the same problem after upgrading to cli 6.1.1 + devkit 0.7.1. Fixed by downgrading
@angular-devkit/build-angularto 0.6.8Before (with coverage issues):
After (coverage working properly again):
brian428 commentedon Jul 31, 2018
I'm guessing something is wrong in the creation or handling source maps?
alexw10 commentedon Aug 2, 2018
Hope this gets fixed soon need to be on latest version of the @angular-devkit/build-angular because of the issue in 0.6.8 of it not exiting with proper error code but now this coverage report issue is a problem.
Willing to try to help fix it as well if anyone can point me where to start looking.
jfpicard1 commentedon Aug 3, 2018
Maybe it's the way that the sourceMaps are handled. If I add "sourceMap": true, in the test section, with @angular-devkit/build-angular 0.7.0 it seems to work.
See: https://stackoverflow.com/questions/51257459/if-else-path-not-taken-in-imports-in-angular-istanbul-code-coverage-report/51676221#51676221
brian428 commentedon Aug 3, 2018
I'm on 0.7.1, and adding
"sourceMap": trueto the test section (or via the command line) doesn't seem to affect the messed up coverage report output.jfpicard1 commentedon Aug 3, 2018
Maybe you have a tsconfig.json with "sourceMap": false ?
Here my DevDependecies:
alexw10 commentedon Aug 3, 2018
I can confirm that setting
sourceMap: truefixed the issue for me I am on0.7.2@brian428 @jfpicard1Guessing this shouldn't need to be on since it worked without it before?
brian428 commentedon Aug 3, 2018
Hmm, updated to 0.7.2, but still no luck. tsconfig.spec.json doesn't set
sourceMap: false. I even addedsourceMap: truejust to try it (even though it's already set to true in the base tsconfig.json), but had no effect. The test section of my angular.json also includes this, but no luck there either:None of these tweaks make any difference. The coverage report is generated but the highlighting is all wrong.
19 remaining items
brian428 commentedon Sep 18, 2018
FYI, I made the local change that was done in https://github.com/angular/angular-cli/pull/12291/files, but the coverage report highlighting is still messed up. Not sure if that's expected for now (I'm on @angular-devkit/build-angular 0.8.1, and don't know if other things have changed beyond that one schema change), but figured I'd mention it.
lanegoolsby commentedon Sep 20, 2018
For anyone here from Google, I may have found a more permanent fix than using the CLI flag. Set "sourceMap": true in angular.json under projects -> [yourProject] -> architect -> test -> options.
Making the change in the tsconfig.spec.json or tsconfig.json had no effect for me.
My environment:
Add --source-map test param as a workaround for broken test coverage
PikaChokeMe commentedon Nov 7, 2018
Thought it might be worth noting that I'm still seeing this issue...
I'm currently using Angular 6.2.7
I currently have "@angular-devkit/build-angular": "~0.8.7",
After adding
"sourceMap": trueto myangular.jsontest options, checking that it was included in tsconfig.json, and manually trying to runng test --code-coverage=true --watch=false --source-map=trueI still have had zero success getting code coverage working and detecting branches properly.richmwatts commentedon Nov 16, 2018
Is there any update on this? I have also set the sourceMaps property to true and believe I am now seeing more "believable" code coverage metrics. However, the highlighting in the reporting is horribly horribly wrong.
How can I have any confidence over the quoted coverage metrics?
jhage-accesso commentedon Nov 16, 2018
This is fixed in ng7
richmwatts commentedon Nov 16, 2018
I am still having the same issue with all dependencies completely up to date
ash4aque commentedon Feb 21, 2019
Does this means it is not fixed for ng6
marthinus-engelbrecht commentedon Apr 13, 2019
This is still broken, running these dependencies
With
--source-map=trueit gives me 100% branch coverage, but with branches0/0. And I don't have 100% branch coverage. With false I get the right numbers but the report is all mixed up.thorstenherbst commentedon Jul 11, 2019
FYI, I'm on the latest versions (Angular 8) and I'm still getting a non-accurate coverage report. Even using
ng test --code-coverage --source-map. IMHO its a bug which is related to a problem with the MAPPING of the source-maps. Not use of source-maps itself.Here is my configuration:
package.json
Angular.CLI
angular.json
If some more informations are needed dont hasitate to write me. I am very interested to help solving this problem.
Thanks in advance
angular-automatic-lock-bot commentedon Sep 9, 2019
This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.
Read more about our automatic conversation locking policy.
This action has been performed automatically by a bot.