rbinder / rbsc.com (Bob Binder) wrote (abridged):
> There is no evidence that this has (or would) have happened for an
> actual implementation. Measuring coverage requires using a coverage
> analyzer or equivalent instrumentation. Simply calling every method in
> a (sub)class interface does not guarantee coverage of the statements
> in the method implementations. Excluding toy problems, it is
> completely impractical to attempt to assess coverage without using an
> automated coverage analyzer.

I mostly agree with this, and it bothers me that XP advocates don't seem 
to pay much attention to coverage tools.

However, it may not be as bad as you think because "test first" 
programming tends to lead to much higher coverage than after-the-fact 
testing. In XP, production code is only written to fix a failing unit 
test. Therefore the test should execute all parts of the new code.

This takes discipline, and is part of what they mean when they talk about 
programming in tiny steps, and avoiding anticipation. Don't write code 
which you think will be needed to satisfy the next test; do not write any 
code which will not be executed by the current set of tests. Always write 
the test before the code, and verify that the test /fails/ without the 
code so you know the code must be executed for the test to pass.

I don't expect this gives 100% coverage, and as I say it bothers me that 
we don't seem to have hard figures about what percentage is actually 
reached in practice. It will give much higher coverage than "test last" 
and I wouldn't be surprised if the coverage was higher than 95%. (I 
appreciate your comments that a remaining 5% will have disproportionately 
more bugs.)

  Dave Harris, Nottingham, UK | "Weave a circle round him thrice,
      brangdon / cix.co.uk      |   And close your eyes with holy dread,
                              |  For he on honey dew hath fed
 http://www.bhresearch.co.uk/ |   And drunk the milk of Paradise."