Unit Testing is best for projects that will be expected to be maintained and added on to over the course of time. If you're doing a small set of scripts for someone's website and your code is 3% of the total codebase, and they want it done yesterday then you sacrifice good design for speed.
Test Driven Development works best if you actually start with the test, no code until you have a failing test. At this point you're coding from the outside in, you're creating your perfect API. Whats the easiest way you can use this class?
Having tests allows you to do one of the most important aspect of TDD which is refactoring. How can you refactor (change the internals of a program without affecting the externals) a program safely without knowing your changes didn't break something that relied on what you just removed?
When working on a team that shares the codebase, what makes sense to one person makes no sense to another, having a unit test backs up your thought process. If a developer comes to your code, they can look at the tests first to see what its supposed to do and then safely make they're changes and run the tests to see if anything fails. If a test fails, you'll know right away that it was your change.
The problem with only having unit tests on a timer is that you don't get the immediate feedback. If you couple constant unit testing as you refactor WITH automated running of the tests you should be ok.
Unit Tests allow you to program for today and re-design tomorrow which is somewhat a contradiction of normal life where you try and design everything perfect from the start, but have you EVER done something completely perfect the first time? Have requirements ever changed on you once you got your great design in place? This is the benefit of unit tests...
With tests you can come back to a piece of code that you know won't scale in the future and modify it safely with refactoring techniques... maybe move it to its own method, or make it a class of its own, etc... all without changing how the overall program outputs data
you'll also find that you name things better which requires less comments to know whats going on.
For example if you're coding the usual way you'll probably want to write the function declaration quick and get to coding the good stuff, so you might call function...
// get some xml string data to use in this function
function getString()
when doing TDD you're testing first so you'll most likely pick a name that is more meaningful to what its doing such as $test->getXMLDataStringFromFile()
now you don't even need a comment, obviously you can do that without TDD but coming from the outside in makes it easier.
k, rant over
