I’ve done it both ways now, and prefer TTD for many reasons. Here’s
some of them:
[Benefit #1]
The benifit of TDD is more than a thoroughly tested application.
-Reducing Under-design: When you miss the mark by not implementing
requirements (either through omissions in the requirements or not
fulfilling them). Bugs crop up as a result.
-Reducing Over-design: When you surpass the minimal work necessary to
fulfill the requirements. The more code you have the more potential
there is for additional bugs.
Both of these add time to a project – translating to higher project
cost.
When you write a unit test first, you follow up by running it and
watching it fail. Next you write code until it passes. Then reduce the
code so it is as clean and minimalist as possible to pass the test.
[/Benefit #1]
[Benefit #2]
You are already doing unit testing in a manner of speaking. You are
just not doing it efficiently or consistently. When you write code you
it there thinking a lot about how to implement it. Then consider the
broader implications the modifications have. This consumes time –
lots of it. And you still don’t know what will occur. You just have to
make your best guess.
When the coding phase begins, you write code and test it iteratively or
you wait to the end and hope it isn’t too screwed up. Either way you
test it over and over. Automated Unit testing in TTD speeds things up
by taking you out of the loop and makes testing more consistent
(obviously).
You spend a lot of time writing them, but you never account for just how
many times they get executed after you’re done. Trust me, That’s a big
number. So, take the amount of time it takes for [you] to sit there
testing your code and multiply it by the number of times the test cases
execute. Now follow the resulting conclusion …
[/Benefit #2]
[Benefit #3]
INSTANT FEEDBACK
Relating to the previous benefit is comfort. How many times have you
been asked if you can make a change and answered, “No Problem” while
feeling concretely certain about your answer?
When you have a robust test harness complimenting your application, you
stop worrying about what you are about to break in the code. Just make
you stinking changes and let the test harness work about the rest of the
problem.
SPEED
Not worrying about the broad implications of code modifications makes
you write write code a a break-neck speed. :o)
[/Benefit #3]
[Benefit #4]
Documenting what the code does and how it does it.
One of the unforeseen products of TDD was the documentation it produced.
It does a great job documenting how a piece of code is expected to be
used. If you think about what a repository of knowledge it becomes,
what a benefit that becomes! Nuff said!
[/Benefit #4]