TDD proponents often claim that with 100% coverage proves that the software works as expected. Whether they actually believe this to be true, or whether they are trying to convince management or developers to jump on to the TDD train, they are headed (and leading) the team to a fall.
The simple reason, is that a test proves that the software works as the developer intend it to. How does this guarantee that the software does what the customer wanted it to do?
It doesn't.
While high coverage is important in order to ensure that the software does what the developer intended, and enables the developer to know how the software works (with the unit test being used as an example of the API), we need Customer Acceptance Tests, preferably automated tests, in order to verify that the customer's intent was captured.
In short, Unit tests and Customer tests are both necessary to ensure quality, as they both validate the software in different, complementing ways.
הירשם ל-
תגובות לפרסום (Atom)
רשומות
2 תגובות:
I don't know who are the 100% proponents, all my incursions in TDD group, Alt.Net group say exactly what you are asserting here.
Most of the people agree that 85%+ coverage is ok, and when you are there trying to arrive to 100% is in most cases unnecessary effort.
Gustavo.
I essentially agree to both statements - 100% as a goal, though I doubt it is attainable on any but the most trivial system. 85% is a commonly accepted heuristic.
As for the "who", they'll remain unnamed, but I've had the pleasure of working with some, and talking, with others.
הוסף רשומת תגובה