Good question. Separate your Dev from QA, and make QA code the automated tests. That way, you still get the eventual safety of test coverage but developers are never slowed by the need to write or rewrite tests.
And what is the benefit of that separation? Seems like that sort of thing makes it easy to blame the other guy "I didn't know to test that / I'm not the tester, not my job".
The "cost" of high-coverage automated tests is overblown, IMO. The few extra minutes spent writing test code is worth the extra safety and confidence. However I believe striving for 100% coverage on every method/branch is overkill.
It doesn't have to be either you do TDD religiously or you have no tests.
I agree. The middle ground is better than writing no tests.
I do think it's more than a few minutes though. The problem is when you do a big rewrite you've now sometimes got a lot of failing tests. Do you go back and delete these tests and write new ones? Or refactor the test code? It's just a big distraction because sometimes you're "holding the program" in your head, as PG would say, and to worry about tests might cause you to lose your focus on the more important code.
