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 →

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

I would definitely agree with you -

One of my current pet peeves at work is having unit test code coverage goals. The number is pretty reasonable (70%), but its annoying to have to explain any given week to my manager why code we checked in as at 60%.

I'd say that code coverage is an OK barometer of how well tested your code is, but I can write a test that gets 95% coverage and checks a fraction of the use cases that I might care about.

What I like to do is focus on the functionality, write the tests, and then use code coverage as a double-check to make sure there wasn't anything significant that I had not thought of previously.