• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Test Coverage

 
Paul Croarkin
Ranch Hand
Posts: 106
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Per and Bruce,

I find that having good test coverage is a prerequisite to agility in that refactorings can be made with more confidence that existing functionality will not break. Of course 100% coverage would be wonderful, but what do think is a minimum on a realistic basis. My gut feeling is that 80% is a minimum.
 
Jeanne Boyarsky
author & internet detective
Marshal
Posts: 34965
378
Eclipse IDE Java VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm not the authors, but here is my two cents.

The code coverage for the method you are refactoring is far more significant than any general code coverage number. Sometimes 100% for the method is still impossible if it was written in an untestable fashion. Then you have to get the highest test coverage you can.
 
Per Kroll
author
Ranch Hand
Posts: 31
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Paul,

I think that Jeanne's answer is a good one.

i would like to add that I think that agility is about more than just a set of code-centric practices as you find for example in XP. Yes, for the code-centric piece, good test coverage is crucial, but there are tons of other practices that are no code-centric that also help you to be agile. So, I do not think that you have to have a certain % of code coverage to be agile, but it certainly helps. In the book we cover both code-centric practices, including 2 practices on testing, as well as non-code centric practices such as risk mgmt and iterative development. You can for example do iterative development so you et fast feedback loops on what you build without having good test coverage, it just harder to do it really well...

My 2 cents. Cheers

/Per
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I don't have my own number (I never measured our code coverage, but it being a legacy system, I know for sure that it's way to low). If I remember correctly, Robert C. Martin - a proponent of Test Driven Development - states that a good team should have a code coverage of over 90%.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Per Kroll:
just a set of code-centric practices as you find for example in XP


You mean like Sit Together, Whole Team, Informative Workspace, Energized Work, Stories, Weekly Cycle, Quarterly Cycle, Slack, Real Customer Involvement, Team Continuity, Shrinking Teams, Root-Cause Analysis, Negotiated Scope Contract, Pay-Per-Use ...
 
Paul Croarkin
Ranch Hand
Posts: 106
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes, I agree that code coverage is not the be all and end all of agilitiy. I do believe, however, that it is prerequisite once you start refactoring, otherwise you will be flying blind.
 
Per Kroll
author
Ranch Hand
Posts: 31
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Iija, touch´┐Ż ...
 
Michael Feathers
author
Greenhorn
Posts: 24
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The important thing to note is that in many old code bases you'll never get all of the coverage you want. It would be nice to have it, and it's good to work for it, but you can still refactor when your code isn't at 90% or 100%. When you refactor you need to have coverage for the areas you are about to change. You have to know what piece of code you'll be changing and figure out where to detect any behavioral changes that could result.

Coverage is great, but it's good know that sometimes you can use a laser if you don't have a floodlight.

Michael Feathers
http://michaelfeathers.typepad.com
http://www.objectmentor.com
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic