TDD is misleading if you don’t realize that it is more about software design and teamwork than testing. According to the authors, an Agile programmer using TDD to write “test-first” code can think about what functionality they want from the code and then partner with a tester to make sure all aspects of the code are performing to that standard of functionality.
While automation saves you a lot of time, it still takes time. You can't run all your tests all the time. It takes too long and would generate an unmanageable analysis and maintenance effort. In my group, we've taken both manual and automation testing to three levels: sanity, end-to-end, and full. In addition to our feature tests, on every code commit, we run a set of high level, cross-feature tests to make sure that a code change in one feature hasn't broken another one. Only then do we run a set of more extended tests specific to the feature for which the code was committed. Then, we run our suite of feature-level sanity tests on our continuous delivery environment every three hours to make sure all features are in good shape. We only do this on one browser though, because we've found that if a test fails, it doesn't usually depend on the browser. Finally, we run feature end-to-end testing on our nightly environment.
I think we can all agree that automation is a critical part of any organization's software delivery pipeline, especially if you call yourself "agile." It's pretty intuitive that if you automate testing, your release cycles are going to get shorter. "So, if that's the case," you might say, "why don't we just automate everything?" There's a good reason: automation comes with a price.