3 ms·
Test coverage is the most conveniently accessible numeric value in the neighborhood of software quality, therefore it is software quality. Merging a change that
by closeparen 6y ago
Test coverage is the most conveniently accessible numeric value in the neighborhood of software quality, therefore it is software quality. Merging a change that reduces test coverage is reducing software quality. That's okay, sometimes we all have to cut corners, but defending this choice means you don't value quality, and are therefore not a culture fit.
/s
- GordonS 6y agoThis is a rampant problem in the enterprise world, and it drives me nuts. I regularly have to work for clients who mandate using Sonar Qube (or/and other SAST tools) with strict policies, and also require 85%-100% test coverage on all projects regardless of how much sense it makes. Predictably, teams have to spend way too much energy getting "waivers" approved by some ridiculous group, and inevitably end up creating tests that don't actually test anything, just to get the coverage figures up.
- lowbloodsugar 6y agoCan you give us an example of where it doesn't make sense?
- GordonS 6y agoA trivial example would be getters and setters for plain old classes.
- lowbloodsugar 6y agoSurely the getters and setters of POJOs would be exercised in the tests of other classes? If not, why are they there?
- dropofwill 6y agoE.g. it’s public api in a library and they’re only used by other applications.
- closeparen 6y agoIn Go, it turns testing into a game of “how do I make this stdlib function return an error”?
- noisem4ker 6y agoError handling taking up 50% of the code is definitely a problem with Go itself. For each meaningful line, there's an accompanying "if err != nil {return err}", so if you want coverage you end up testing this kind of boilerplate.