Not sure if I trust this argument, before we can really discuss it: 1) Write test to prove TDD exists 2) Write test to prove TDD is a tool 3) Write test to pro

Not sure if I trust this argument, before we can really discuss it: 1) Write test to prove TDD exists 2) Write test to prove TDD is a tool 3) Write test to prove TDD gives feedback given good input 4) Write test to prove TDD gives feedback given bad input 5) Write test to prove TDD gives feedback given no input 6) Write test to prove TDD gives feedback given mulitple input(s) 7) Write tests to define how a religion should respond to certain criteria. 8) Write test to prove TDD when try to be used as a religion fails. 9) Mock TDD, in a friendly kind of way. :-) Yes, there are good points and bad points to TDD. I'm glad the concepts, debates, and frameworks exist. Even if I don't follow them 100%, they do help me to think about a lot of that stuff in projects I design. In everything, moderation. Currently I prefer thinking, tinkering, REPL/playing design until I have a basic structure working, and I can see how I want it all to work, and then write tests afterwards, fixing any bugs that the tests reveal. Experiment-Driven-Design, Test-Driven-Maintenance. This probably only works for small projects, though.