A lot of folks in the RoR community are into the concept of Test Driven Development. The logic of it makes sense to me, if the implementation doesn't.
Here's the main argument. A guy becomes part of a team. He is a TDD guru or disciple, all about testing. He believes every piece of code written should have a test written for it first. This is the part I can partially get behind, since writing tests makes code easier to handle and understand. So what's the issue?
Basically, it boils down to these words: EVERY PIECE OF CODE WRITTEN. Really? Coverage percentages do not indicate success. As a matter of fact, the only thing they indicate is a frenetic desire to write lots of test code. I feel humbled as a lesser developer when I don't use the TATFT principle. It's a great principle, but when you find your tests extending into scripts 10 times larger than the code, it's time to re-examine what you are doing.
I'd like to work on a concept that is slightly different. This idea is CDD, Customer Driven Development. This is easy to grasp. You will still write tests for you code, it's unavoidable and it should be done, without getting out of hand. The difference is not spending exorbitant amounts of time changing your tests every time a customer changes their whimsical mind. If simple changes break your tests, maybe TDD isn't the best option for you.
That being said, TDD is good, but needs to evolve past the idea of coverage and tests for the sake of tests. Good code is seen with or without them. Is it possible I'm wrong? Absolutely.
I am just waiting for the one thing (and I don't know what that might be) that will turn me into the frenetic Test Guy in the office.