[mlashcorp]

I may be in the minority, but I find the 50% unit test coverage not useful, and sometimes harmful. Caveat emptor - depends a lot on the project, and how often you are changing the code and/or the complexity of said code.

[sidlls]

Join the club, then. My view is there is a borderline unhealthy obsession with unit testing to the point that the actual product code takes a back seat (in quality and functionality) just so that some usually arbitrary measure of "testable" applies to it.

[ck425]

Same here. Coverage is no indication of quality, and lack of coverage isn't necessarily an indicator of lacking quality.

[Ace17]

> lack of coverage isn't necessarily an indicator of lacking quality. "lack of coverage" mostly means "untested code".

My experience is that it's very hard to keep untested code to a high quality level. Any modification that isn't directly justified by a customer feature or a bug fix is frowned upon, because it's hard to tell if it breaks anything ; which means you pile up new features, but you can never modify their design so they fit better together.

When the philosophy is "now it works, let's never touch this module again!", code quality goes down to the toilet.

[marcosdumay]

In addition to that, how did he settle it on unit tests instead of integration tests?

[ferroman]

What do you mean? Is it's too low or too high?

[quantumhobbit]

It is less a question of whether the percentage is correct than whether the tests are useful. I've seen plenty of useless tests (testing getters and setters in Java) that assert nothing related to the codes functionality but exist solely to boost coverage. Which is why asserting a strict coverage percentage is dangerous.

Better to just do real TDD in the first place.

[mlashcorp]

In my experience it's too high. I see a lot of unit test code that doesn't do anything except add complexity. But again, I guess this will depend on the nature of the project