It's the repetition of the test  that wins you time later. If the code is not going to change, you'd better hand-test it and then leave it when you're sure it's all good. But even in a small software, everything is changing every day, and there's a huge dependency graph that makes it impossible to track changes. So, instead of testing everything all the time (at least on each release), you make some robots to test everything for you. Of course this is more expensive than hand-testing a few times, but later it pays off. Especially in large scale systems that the time for test would increase exponentially over time.



A VERY important point is that you should maintain tests the same way that you should maintain the software. So, "designing" tests to be maintainable is very important, as you would design your software to be maintainable.



Anyway, I'm not a big fan of TDD for the whole project. And I'm not very happy with the Unit Testing either. The last time I used TDD was for the development  of a core class library for a project which is the architectural glue. I wrote unit tests instead of defining the interface, and asked a team mate to develop the library in a way that all the tests are passed. That was rather a definition than a test, but it had the benefits of TDD too.



Otherwise, I use functional tests. A large software cannot work without a test team. Spending time to write automated test scripts is a good investment, because you need a test team in a way or the other. Why not ask them to write repeatable tests? So, I'm not using TDD, rather "Test Driven Maintenance". When a change occurs, the functional tests can tell you what went wrong, or which test should be changed. (But I have big troubles for windows apps on this!)



Unit testing every aspect of every component is very expensive, and I think it is suitable for rare cases, like when you need an extremely high quality software (like for airport control towers), or you plan for a big number of re-uses (like product line architectures). Otherwise, if a fault in a specific component does not affect the working of the whole application, then it's not a bug.