1. It is only fast if you are working solo on a project for less than 2 months. Each extra person, subtract two weeks. Think larger scale than just adding a fea

1. It is only fast if you are working solo on a project for less than 2 months. Each extra person, subtract two weeks. Think larger scale than just adding a feature. You always have to refactor to add the next feature. The giant mess you created takes time to understand and change. With tests, your abstractions actually work. Focus on what you need to change, change it, fix the failing tests, repeat. 2. If having tests during a major refactoring/redesign slows you down, you are writing the wrong kinds of tests. Changing code should break your tests. Not all of them, but the ones where you have changed the behavior. Unit tests are more valuable than integration (rails controller tests) tests which are more valuable than functional tests (browser/request). If all you have are the later, they will break for everything and provide little feedback as to the cause. More general tips. Test logical switches, not assignments. If you have to deal with lots of mocking, try to avoid state mutation and use a more functional approach. Mocking is a result of interaction testing. Code coverage only tells you if you are lacking in quality, not that quality is present. 100% doesn't mean you have good tests. Test what matters, don't test everything. I realize your argument is for using TDD all the time. The problem is that your complaints are from the standpoint of, I never want to test anything. There are very valid reasons for not using TDD all the time. You just haven't listed any.