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.
