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?