From: olczyk@... (Thaddeus L Olczyk)
Date: 2001-12-11T23:03:02+09:00
Subject: [ruby-talk:28218] Why writing tests first can't work.

On Mon, 10 Dec 2001 23:38:57 -0800, "Kent Beck" <kentbeck@my-deja.com>
wrote:

>> 1. What about oddities in the source code? Like:
>>
>> if (any side ==4) {
>>     return 1;
>> }
>>
>> This would cause it to fail for the test case 1,2,4 and your tests
>> would miss that.
>
>Don't put oddities like this in your source code. Working strictly test
>first, there would have to be a test that was failing before the conditional
>above was written.

Tsk. Tsk. Where have you been? This technique for fixing a bug is one
of the most attractive techniques for fixing a bug there is. Even
highly intellegent programmers who do know better occasionally become
tempted. Albeit under more subtle circumstances.

In fact one of the most renown bugs in Visual C++ 4.2 was caused by
precisely this attitude. There is a bug in the string class that
caused the string to crash on deletion. The conditions of the bug were
that you assigned a string of length  32 or more, then assigned a
small string. When the string assigned to was deleted your program
would crash. Someone fixed this problem by changing the string
class so that the assigned to strings reference count was not
decremented on assignment. Resulting in a large memory leak.

While much of the reason for this problem is the shear stupidity of
some programmers and the insistence on *doing the stupid thing*,
some of the reason smarter programmers do it is that it makes
sense sometimes. ( Eg. in a routine where you calculate the cube
root a number which sits on the strange repulsor should be handled
in this way. )


It should be pointed out that by XP criteria the tests are the specs
and that if those lines of code caused the tests to run successfully,
then the code is up to spec, and the code is not an oddity.