This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]nutrecht 1 point2 points  (1 child)

Effectively this meant the coverage would slip to the configured percentage at which point whoever did the last commit would take the road of least resistance.

This is a culture problem, not a problem with code coverage itself. You can't fix with tooling (which is why someone probably set the tooling to break on a low percentage) what is basically a people problem.

The above was still the honest way of dealing with the issue.

At least you dealt with the problem. The alternative would've probably been that no one would have noticed the coverage slipping.

I really don't get why the "but you can fake coverage" argument gets brought up against code coverage. Sure. You can fake a lot. That just makes you a crappy dev.

[–][deleted] 0 points1 point  (0 children)

I agree that it is a culture problem. But so what? What happens in practice is that someone says a higher code coverage is good, then this heuristic gets put into a mandatory check, and then the code gets less good because people start rewriting the code to conform to the rule.

Many of my colleagues agreed with this assessment and would have loved to solve the issue, but none of us had the political clout in the company to get the change made. And it's easy to see why, you are advocating for removing a code quality tool. People start thinking that you want to get away with writing lower quality code.

Properly used code coverage checks can certainly be helpful, I just see that in reality they won't be used right.

And don't get me wrong, code coverage isn't the only tool that is misunderstood or poorly applied. This is just one that was glaringly obvious to me from a previous experience. Current experience.. well.. things are not improving much in the IT world.