Scott Hanselman

browse by category or date

Test Coverage IS important...

February 18, 2004 Comment on this post [4] Posted in Programming | Tools
Sponsored By

This fellow said:

"I would much rather aim for 100% test-driven development than aim for 100% test coverage."

But I fear he's missing the point.  If I'm only testing 1% of my code paths, 100% of the time, what am I accomplishing? Squat. 

As my boss has said, adding a non-intrusive code coverage tool to an already successful unit-testing strategy can absolutely find gaps in coverage that staring at the screen just won't find. 

But juxtaposing 100% TDD with a 100% coverage goal doesn't make sense.  They are complimentary, parallel even, but not opposing goals.

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook bluesky subscribe
About   Newsletter
Hosting By
Hosted on Linux using .NET in an Azure App Service
Comment on this post [4]
Share on BlueSky or use the and post anywhere!
February 18, 2004 19:19
By aiming for 100% TDD, one can get 100% statement-coverage and branch-coverage as a side-effect. It's not that coverage isn't valued, but that getting coverage via TDD is easier than trying to get coverage by after-the-fact unit testing.

TDD's rule is "write no line of code without a test to force its existance." So that pretty much guarantees 100% statement-level coverage. The rule also applies to "if" statements, etc., so you don't write an "if" statement unless you have a test to force it to exist - pretty much guaranteeing 100% branch-coverage.

keith ray
February 19, 2004 0:38
Don't forget the Pareto principle ( 80/20 ), or your 100% may turn and bite you in the a$$ =)

BTW, TDD doesn't ensure 100% code coverage. Actually, the term TDD is somewhat of a misnomer, and Example Driven Development is a more term to describe the actions going on.

Any professional tester will look at tests appearing in a TDD projects and say "OK, good start, but where are the security, performance, scalability, etc tests ?"

IMO, TDD is an excellent design tool, allowing us to express in no uncertain terms (?) the behaviour we want - and then implement. Its just like a safety net, it'll keep you from nose-diving into the ground when changes occur, but its still got lots of holes - testing wise.
Udi Dahan - The Software Simplist
February 21, 2004 3:07
The problem with aiming for 100% test coverage is mainly the ways developers go about getting there when they are "forced" to by management. Setting it as a personal goal is very admirable, making it a requirement for a team is suicide.
Peter Provost
February 25, 2004 1:37
I am not aware of any modeling tools to drive tests that do not require hand tweaking of code to make sure that you can catch all of those strange error conditions that you code to protect against. To be honest, in my experience, only the organisations at the top of the software foodchain really apply these methods, and they get the rewards. If you are apply any of these techniques, you are probably in good shape.

I guess its like a joiner, who has a wide range of tools in his bag. For some jobs, you may be able to take a "good enough" for the price approach, yet you may also get another job where not applying a little vigour may result in disaster.

Stuart.
http://www.gotdotnet.com/Community/UserSamples/Details.aspx?SampleGuid=881a36c6-6f45-4485-a94e-060130687151
Stuart Richardson

Comments are closed.

Disclaimer: The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.