[mattvanhorn]

Actually, TDD is the way you figure out what you are building. People who start with a solution in mind may write tests first, doing a kind of pseudo-tdd, but they are not reaping the benefits of letting the requirements drive the design.

This is NOT TDD:

1 - Think of a solution

2 - Imagine a bunch of classes and functions that you just know you’ll need to implement (1)

3 - Write some tests that assert the existence of (2)

4 - Run all tests and fail

5 - Implement a bunch of stuff

6 - Run all tests and fail

7 - Debug

8 - Run the tests and succeed

9 - Write a TODO saying to go back and refactor some stuff later.

see: http://cumulative-hypotheses.org/2011/08/30/tdd-as-if-you-me...

[bhousel]

I don't think we necessarily disagree. In the blog post, it looks like the author was training people on "true" TDD by using pair programming and a simple game like tic-tac-toe or rock-paper-scissors as the "target". This worked because teams were using TDD to evolve their design into something that they already knew pretty well.