jest feature request: automatically raise coverage?

Currently, if I have coverageThresholds defined, jest will (correctly) error out if any of the 4 metrics is below their threshold.

However, when coverage goes up, i'd like a way to automatically bump the thresholds to match the new, higher, coverage values.

One or both of the following would be helpful:

a command that exited nonzero when coverage did not exactly meet the (whole-number-rounded) thresholds
a command that updated my jest config inline (whether in package.json or a separate file) to make thresholds match current values, only if they are not lower than the current ones.

Jun 01 '17 21:06 ljharb

I really like the idea of a bump-thresholds command. Currently I've just been setting them all to 100, running coverage, getting the values jest states, copying them to my jest config. We do this every fortnight to lock in coverage gains.

Jun 06 '17 08:06 camjc

The problem with trying to update inline would typically require committing those changes back to your source control repository. I wrote a script that we use as the testResultsProcessor and loops over all of the coverage to print out the current configured thresholds, the newly calculated thresholds and the difference between the 2. Makes it really easy to see how coverage changed and what numbers need to be updated. If you're interested: https://gist.github.com/bookman25/bc782c56062c03f34d34933563575778

Jun 06 '17 11:06 bookman25

Indeed, the result of running with this feature enabled would be a git diff that I'd then have to commit to my repo if I wanted to keep it.

Jun 06 '17 15:06 ljharb

Should this be a flag (similar to -u for snapshots) or do you want it automatically raised for every single test run, as long as it goes up (and is a test run for all tests, not just a subset of tests)?

Oct 10 '17 15:10 SimenB

I mean, it shouldn't do this by default if that's what you mean; that'd be needlessly surprising and semver-major. A flag sounds good, and imo it only makes sense to invoke when coverage thresholds would otherwise be enforced (given the proper flag)

Oct 10 '17 16:10 ljharb

👋 What about some sort of upper threshold? I would like jest to break if my threshold is much higher than the one configured. It could be done on a per threshold basis:

functions: [85, 90],

or a fixed number to be defined somewhere? I would just want to be notified if the threshold increases, it is sometimes hard to keep it up to date.

May 21 '20 07:05 icatalina

FYI, there is a https://github.com/Koleok/jest-coverage-ratchet project that is doing what people want here, although it properly works only with thresholds defined in package.json, not in jest.config.js.

Jun 14 '20 14:06 Litee

@Litee Actually that package hasn't been updated for a while and I am still facing a lot of issues with it 😞

Jan 24 '22 14:01 tqn-treezor

@tqn-treezor Well, since I made my comment I created https://github.com/Litee/jest-coverage-thresholds-bumper and use it a lot in my team.

Jan 25 '22 22:01 Litee

@Litee Awesome! I actually made it work, but from the activities of both of your packages, I might switch to yours ^^

Jan 26 '22 08:01 tqn-treezor

It would be really great to add this. As other people have said above, the easiest manual process is to up values to 100, let it fail, then use the error message to copy and paste back into package.json. Whilst there are multiple packages that have attempted to do this, they don't work in all circumstances and / or don't handle multiple thresholds. They all seem to rely on json_summary to provide the data they need to work, but any implementer needs to then apply the multiple thresholds correctly to get the correct percentages (as far as I can tell). If updating the config is too much, at least having an option to output the coverage info in the same format as the config file so it's a simple copy / paste job would be a time saver and make it super easy to then go that extra step and overwrite the values perhaps? (the failure message when the values are upped to 100 almost matches the config perfectly, so I assume this wouldn't be too difficult)

Just in case anyone else finds this and is looking for something similar, as of this posting:

https://github.com/rbardini/jest-it-up - package.json config is unsupported
https://github.com/markis/jest-ratchet - doesn't work with multiple thresholds
https://github.com/Litee/jest-coverage-thresholds-bumper - doesn't work with multiple thresholds

It's also a common scenario because you can isolate problematic code with different thresholds and then slowly raise the quality bar of your project.