"Do you think the customer is going to get angry if you explain that part of your development process is to execute the code you just wrote to make sure it doesn’t crash? If the answer to that is “no, of course not, that’s ridiculous” then you also have the answer to whether or not a customer would care if you happened to automate that process."
1. Don’t ship any new features without writing unit tests for them first.
2. These new features most likely rely on parts of existing code so write a few tests for that existing code with each new feature.
3. If something breaks in production write a test for it at the time that you fix it.
Little by little you’ll increase your code coverage without grinding development to a halt.
I actually thought the same way you do until just recently. Once you get into the flow of writing unit tests, you'd be surprised how little time it takes, and how effective TDD can be. It helps me stay focused, and structure programs better. I can't say if it actually has slowed my development time at all, when you take into account fixing bugs found in functional testing.
