On 11 Dec 2001 06:55:24 -0800, rbinder / rbsc.com (Bob Binder) wrote:

>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.

Bob, thanks for a comprehensive report on coverage. I am a bit
surprised, however, because you seem to  me to be (sort of) saying
that theory says you can't accomplish what Beck actually accomplished
in practice.

What seems to me to happen when one goes strictly test-first is that
one gets very high coverage, of all branches. There are exceptions ...
and exceptions are one of them. Often in Java you can't even get a
statement to compile unless you embed it in a try block. This forces
the programmer to code both sides of the block while he only has a
test for one side. 

Overall, however, the practice gets very high coverage, which (while I
agree it is at best the beginning, not the end of good testing) is
very much higher than programmers "generally" accomplish.

What you didn't much address is whether this little example needs more
tests or not.  In my view, it does not (after the one for not a
triangle, which has been provided). It certainly seems not to require
22.

With all due respect, your theoretical answer seems to me to try to
sweep aside an interesting practical result, of which this toy is an
exanple: the test-first practice seems to produce code which needs far
fewer tests than black-box theory would suggest. It might just be an
artifact of the example, except that many of us who are using the
practice observe that it works well all around. 

My belief is that test-first is in some sense a different kind of
testing and programming from the joe codes it and jack tests it kind
that we have used in the past.

I could be wrong ... I frequently am,



Ronald E Jeffries
http://www.XProgramming.com
http://www.objectmentor.com