Hacker News new | past | comments | ask | show | jobs | submit login

This is true.

You can have bad unittests which make the system worse and you would be better of without them. You can also have useless unittests with 100% coverage, which is pretty much the same as bad tests because more code means more bugs and more work. Unittests are also code after all.

The only thing you can say about a very low coverage is that you probably don't have good tests. That's not a very useful metric, since you likely already know that.

The metric 'coverage' is almost useless. Code coverage starts to be useful once you let go of it as a goal and ignore the total percentage number. I found it is very useful though if you can generate detailed reports on each line of code or better yet, each branch in the code, indicating whether that line or branch is tested. Eyeball all the lines which don't have tests and ask yourself: would it be useful to add a test exercising this codepath? How do I make sure it works and what cases can I think of that could go wrong? This doesn't automatically lead to good tests, but it helps you spot where you should focus your testing efforts.

Code coverage is a good tool to help think of test cases, as a metric for the total codebase it is nearly useless.




> Code coverage starts to be useful once you let go of it as a goal and ignore the total percentage number

When a measure becomes a target, it ceases to be a good measure.

It takes immense discipline to actually let go of a metric to keep it valuable.


Funny thing that 100% coverage really helps for dynamic typed languages. It's easy and helpful.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: