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