Because of my experience as a freelancer and solo founder, I found that test-driven development eases the burden in the later stages of a project when too much of the time is spent debugging stuff that breaks whenever I touch the code. TDD deals with this problem preemptively and is therefore the Holy Grail of software development processes.
… Or is it?
Trouble is, web development these days is all about frameworks. Take a look at the file structure of any project and you'll guess the framework it is built upon before you get any clue about its purpose. This reliance on frameworks has heavily leaked into testing. Even if you're just testing a Symfony2 service, you're still parsing tons of yaml files and booting up the kernel and injecting dependencies and god knows what else before your service is actually tested. This slows each test quite a lot, which is troublesome if your suite runs hundreds or thousands of tests.
TDD is based on the idea that you write your test first, just enough to prevent the suite from passing. Then you implement some code that makes the test pass. Then you refactor that code so that its cleaner and more efficient. In between these steps you should run your test suite. An entire "write test, run tests, write code, run tests, refactor code" (the Red-Green-Refactor cycle) should take no more than a couple of minutes, which is difficult when justs running the tests takes an hour.
The answer is moving application logic away from the framework. Uncle Bob says it better than I ever could:
Inspired by this talk, and having seen first hand the problems with the test-later approach, I've been doing some experimenting with the idea of a use-case driven approach in php which dispenses with frameworks. I just put on github what I've come up with so far. Called it TeDDy, after the TDD acronym, and I'm using it in my current project, which I started this week. Right now it's running all its tests (30+) in less than a second. Nice.
There's a lot of potential in this idea.