I, on the other hand, have grown to love tests more and more.
Not for reasons of finding bugs – though that is often a nice side effect – but because once I have decent test coverage I don't need to look at the application anymore. Being able to run the tests in the background to verify my work is sane, while I move on to the next feature in parallel, I find, is considerably faster than the code/build/review cycle you find yourself in without a decent test suite.
My own performance, being a limited commodity, is the most important factor and I find tests help me increase output, not slow it down as you suggest. They are certainly not a panacea though. As always, use the right tool for the job.
I personally can't rationalize skipping the "review" part of the cycle. If it faces the customer, it's my responsibility and the luxury of not looking at it seems like trading away effectiveness for efficiency.
I see your point. I also take on design roles, so I naturally do that extra double take on the work during the design phases. Though I generally find the tests really do a great job of covering what they should.
If you are working with larger teams with designers and developers, I suppose it may not work out as well.
Not for reasons of finding bugs – though that is often a nice side effect – but because once I have decent test coverage I don't need to look at the application anymore. Being able to run the tests in the background to verify my work is sane, while I move on to the next feature in parallel, I find, is considerably faster than the code/build/review cycle you find yourself in without a decent test suite.
My own performance, being a limited commodity, is the most important factor and I find tests help me increase output, not slow it down as you suggest. They are certainly not a panacea though. As always, use the right tool for the job.