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.
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.
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...
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%.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Joined: Jul 11, 2001
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 ...
Joined: Sep 30, 2004
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.
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.