TDD is BS?

[Walter Bright]

On 6/20/2013 2:49 AM, Jacob Carlborg wrote:
> On 2013-06-19 23:54, Walter Bright wrote:
>
>> TDD strikes me as an ad-hoc way of constructing code, and is a poor
>> substitute for thinking about the problem as a whole. For example, I
>> don't really see how getting a square root function to pass its test
>> cases is going to lead one to implementing one of the classic algorithms
>> for computing square roots. I don't see how TDD for a compiler will lead
>> one to rediscover what is known about the best way to organize the logic
>> of a compiler.
>>
>> TDD is "curve fitting" which is what one does when one has no
>> understanding.
>
> I have not watch the video(s) but I think you completely failed to understand
> what TDD is about. This is how I think about TDD:
>
> 1. You have a problem to solve
> 2. You think about how to solve the problem and how a design can look like
> 3. You come up with a design
> 4. Write a test according to the design
> 5. Write the implementation
> 6. Run the test to see that the implementation matches your design
> 7. Repeat 2-6 until satisfied

Uncle Bob's 3 laws of TDD:

1. You are not allowed to write any production code unless it is to make a 
failing unit test pass.

2. You are not allowed to write any more of a unit test than is sufficient to 
fail; and compilation failures are failures.

3. You are not allowed to write any more production code than is sufficient to 
pass the one failing unit test.

http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd

Your procedure is much more reasonable, but I suspect the latter is more 
"principled" TDD, although it is fairly absurd as it implies a complete lack of 
understanding or design, and was what I was referring to.

And, btw, your lexer example of TDD is exactly what I think is wrong with TDD.