Disable jest coverage in MRs
What does this MR do and why?
This MR disables jest coverage in MRs because jest coverage currently causes an issue with slow/hanging CI jobs.
See #501173 (closed)
Original reasoning
This MR serves as a discussion starter.
This removes jest coverage in MRs to speed up our jest suite. Unlike with Ruby, in my four years as community contributor, I’ve never seen an MR be held back because of the lack of generated coverage, only by reviewers who suggested to add or improve test coverage.
Alternatively, we could add undercoverage (like we have for Ruby) but:
- I don’t believe in the efficacy of that as quality instrument (-> is the frontend code (63% lines covered, even less with templates) more buggy than Ruby (98% lines covered)?) and
- jest coverage is inaccurate anyway since it can’t collect coverage on the templates.
(Unrelated to this change:) I’d even go the other way further and consider adding more static typing—instead of tests—to e.g. our GraphQL queries (since this type info is already available), so we can give engineers more confidence in using data across the frontend and statically lint errors.
MR acceptance checklist
Please evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.