From: Ron Jeffries Date: 2001-12-17T04:55:44+09:00 Subject: [ruby-talk:28706] Re: test-first On Sun, 16 Dec 2001 17:28:11 GMT, Daniel wrote: >This is a single general response to the replies written by Mr. >Jeffries, Martin, and Roth... These are separate replies to just a couple of points, and not to be taken as agreement or disagreement with the rest of Daniel's fine document. Mostly I agree or sympathize as appropriate. > >Yes it is possible to write a test to see if your collision detection >algorithm works but that means nothing. What is important to the user >is that the ball bounced off the paddle. Just because I have a working >collision detection algorithm doesn't mean the ball on the screen will >bounce correctly. This is not consistent with my experience. If the collision detection code does NOT work, the ball will not bounce correctly no matter how hard we look at the screen. Having the algorithm work means a lot more than nothing. What Daniel may mean by "means nothing" is that it isn't sufficient. It is often the case that the collision algorithm needs to be tuned for best visual effect. The most common tuning is to adjust the logical boundaries of the objects compared to the physical ones. This can often be done with a single adjustment of an error factor in the collision detector, but sometimes the individual objects need to be adjusted. > >Mr. Martin claims that XP "advocates writing tests that are so simple >that they can be eyeballed to work." I say that all your functions >should be written that way. In which case, the tests are superfluous >because we can just look at the function and know it works. (Assuming, >of course, that all the functions this one calls work. :-) I find that I cannot look at my own code as I write it and know that it works. (Actually, I know that it works. It just doesn't work anyway.) So I write tests. It is uncommon, though possible, to write a test that incorrectly shows that incorrect code works. So the tests tell me that my code works in ways that inspection cannot. And they tell me again tomorrow when I change the code. Of course inspection is another way to increase the odds that the code works. Pair programming or code reviews provide this service. I don't know whether Daniel avails himself of these or not. If quality and delivery speed are high enough, there's no big push to add inspection. If one is producing code that is as correct as it needs to be, and that is produced as quickly as it needs to be, measured by customer satisfaction, then one need not consider changes in process. If one is spending measurable time in debugging, however, one possible process change to consider is more automated testing. Regards, Ronald E Jeffries http://www.XProgramming.com http://www.objectmentor.com