Comment Re:Letting it all out (Score 1) 55
Good post. I'm with you on the "I'll take my programming with strong typing and lots of built in idiot-proofing." Personally, I view writing unit tests as an extension of that mentality. I think of it as writing the code twice: write the code (the actual system), and write what the code is supposed to do (the tests). If they don't match, I've done something bone-headed. As long as the tests are part of your build, it's exactly like augmenting the compiler checking. I can't tell you how many times writing tests have caught my own bone-headed mistakes, even in "too simple to be wrong" cases. I'm no TDD fanboy, but in my experience writing tests usually pays for itself pretty quickly timewise.
You mentioned a situation where a refactoring would have been great, except it would break 50 other tests. When I read that, I thought your tests probably did you a favor: that seemingly trivial change would have actually caused a lot of other failures that you didn't expect. Unless the unit tests were badly written. I've seen that before, and yeah... badly written unit tests are as much of a nightmare to maintain as any other badly written code, but without the benefit of providing any customer value! If someone's only experience with unit tests is a poorly written test suite, I can totally understand how that'd sour them on the TDD concept.