These two screens say it all:
It's the same code without any changes. It's just that the first time no tests ran (because none changed since last commit), and thus coverage reported 0%.
Should we disable the "lazy run" logic when coverage is requested?
This is why I repeatedly said that using coverage in watch mode isn't very useful. I think it would be smarter to allow coverage only when you run all tests in this mode but not sure how to best signal it.
I definitely agree the behavior is initially confusing, but I think coverage + watch mode does enable a pretty nice workflow after you realize it's only reporting on what ran last. I keep thinking how nice it would be to pair Jest's watch mode with some kind of coverage server that could reload the html report when it changes. No more alt tab and refresh, just write tests and watch the red code change to green code.
One thing that probably should be disabled for coverage + watch is the coverage threshold error though.
Is it possible to display only the coverage of the changed/affected files? That would be really great to see as I'm writing tests. Unsure how possible that is.
Similar question as above, would it be possible to perhaps configure a parameter that controls/overrides collectCoverageFrom
so that you can generate coverage for only part of an app?
@moaazsidat Tangentially, today I discovered that, in order to see coverage information when watching a pattern, I had to provide a similar pattern again via --collectCoverageFrom=[similar pattern]
.
It'd be great if there were some option to show coverage _just_ for the watched patterns!
Most helpful comment
Is it possible to display only the coverage of the changed/affected files? That would be really great to see as I'm writing tests. Unsure how possible that is.