Re: [OT] TDD only works for simple things...

Adam Kennedy wrote:
> - It can test the things you know that work.
> - It is good when testing the things you know that don't work (its 
> strong point)
> - It is not good for testing the things you don't know that don't work.
This implies that TDD is about code quality. For me, I find that a big 
part of the value of TDD isn't about this.  Here's a few benefits that I 
experience:
1. Writing the test first lets me "role play" my API.  I might rewrite 
the API a couple times while writing the first couple tests because I'll 
get to see how it works in practice.  These changes are nearly free, as 
I've done no implementation yet.  (Nor do I have to change Pod/spec, 
because I haven't written that, either.)
2. It forces me to work in small chunks.  I define a specific coding 
task by way of a *single* test (not a whole test file).  Then I 
implement that test.  I get an immediate feeling of accomplishment each 
time a test passes.  (I think those who get "addicted" to TDD are really 
getting addicted to the dopamine/endorphin/whatever hit from frequent 
positive feedback of task completion.)
3.  It encourages YAGNI.  By keeping focused on passing a single test, 
coding is focused.  I don't write things I "might" need/want until I get 
around to defining a real case for it and embody that in a test.
4.  It protects me against myself.  As I add each small piece of code, I 
get continual feedback that I haven't unintentionally broken anything else.
I do realize that it's easy to get bogged down in all the ways to do 
"Evil Testing".  There is a mixture of art and science in TDD.  The way 
I manage is that I focus on positive testing and code first -- i.e. 
getting the code doing what it's supposed to given proper input.
Only once I know its working properly on valid input do I expand the 
tests to seek out invalid input, etc.  And I mix this with some coverage 
testing to ensure that I haven't inadvertently created defensive code 
that wasn't actually part of passing a test.  (Generally, conditional 
branches not taken are what show up here.)
Regards,
David Golden