Ron Jeffries <ronjeffries / REMOVEacm.org> wrote in message news:<176717160028CE03.51B6AF6E20305FB5.2EC5DCFFD6C10DFD / lp.airnews.net>...
> 1. You start with a clean text buffer: no code.
> 2. You have something in mind you want your program to do. Something
> tiny: the first little bit.
> 3. You write an automated test to prove that your clean text buffer
> doesn't have that feature.
> 4. For a while the test doesn't compile. You add just enough code to
> the buffer to make it compile (typically a class definition or
> function declaration).
> 5. For a while the test doesn't work. You add just enough code to the
> buffer to make the test run.
> 
> At this point, you have tests (1) that run automatically, that are
> comprehensive, and (it turns out, I have no proof for this) they're
> easy to maintain.
> 
> Then you think of one more little bit the program might do. You write
> another automated test to see if the program does it ...
> 
> As odd as it sounds, this really works. It does take practice, and you
> do have to go in TINY steps. No, tinier than you are thinking. 
> T_I_N_Y.
> 
> Since you like tests and tested code, you might like to give it a try.
> There's a small example in XP Installed, and Chet and I give
> demonstrations at various conferences. The Spring Software Development
> is a strong possibility for the next public session.
>

I am interesting in your use of the word "comprehensive".  Beck gave an
example of test first coding where he wrote the test case:

sum = Calculator.sum(2,2)

assert: equals(sum,4)

Then, he said we could proceed to code the sum method of Calculator.
Is this an example of a comprehensive test?  I guess Beck could have
just been giving an example that was less complex than real-world
TFD, so he did not mean it to be comprehensive.

What would the comprehensive test that should be written first look
like for Calculator sum?