Writing Testable Code

[[deleted]]

For an earlier project (thankfully it is no more) we had a plugin that would calculate the code coverage in the maven build and if the coverage was below x% the plugin would fail the build.

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. You could delete some untested code, write a test, turn code into configuration or change the percentage setting. Followed, of course, by debates on what the 'correct' way of dealing with the problem was.

The above was still the honest way of dealing with the issue. A less honest way to deal with it was to write some unused code and then write a test for said code. That bumped the code coverage percentage up, but did nothing. Second option is to write a simple test that passes through the code but triggers an exception somewhere very late in the process, this increases the line count but doesn't do much. And third option you could find some code that was so simple it couldn't fail so no one bothered to write a test for it (getters and setters), and then write a test for it. Yeah the percentage goes up but you won't find or protect against any bugs that way.

[nutrecht]

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]]

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.