Hacker News Reader

Comment by closeparen | Hacker News Reader

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.

View on HN

This 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.

Can you give us an example of where it doesn't make sense?

In Go, it turns testing into a game of “how do I make this stdlib function return an error”?

Error 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.

A trivial example would be getters and setters for plain old classes.

Surely the getters and setters of POJOs would be exercised in the tests of other classes? If not, why are they there?

E.g. it’s public api in a library and they’re only used by other applications.

Reply on news.ycombinator.com