[rstuart4133]

I don't agree with him.

Everyone knows when you are forced to write tests you code differently because you have to make the lines tested visible to the testing code. In legacy code without tests no one bothered to do this, which is why adding tests to legacy code is near impossible.

If 100% test coverage isn't forced you end up with lines that aren't visible to unit tests without re-factoring. If a bug is found in those lines and you want to add a test to demonstrate the bug has been fixed, you can't just make a minimal change - you have to re-factor the bloody thing, increasing the odds you will introduce another bug.

The bottom line is ensuring you have 100% test coverage (or even better 100% branch coverage) brings it's own rewards because of the discipline it enforces in code structure, and that is true even if those test lines don't do much in the way of useful testing.

So for me his argument only works you have 100% coverage. Thereafter, yeah, each test has to earn it keep.

[patz]

Actually this piece code is to achieve 80% test coverage or even lower. (It's the target of another remote team.)

From the observation, "Everyone knows when you are forced to write tests you code differently" doesn't hold. If you try to make your code testable, TDD is a better approach. (which means you have to write test first.)

But to people who doesn't know how to make code testable, or even worse, take test coverage goal as a burden. They code before they integrate, they integrate before they test. Such stories happen a lot.

Only if people believe in test first and help them know how to write good/maintainable tests first, can test coverage goal make sense.