3) Are your refactoring steps too big? (Is it actually a "rewrite"?) Or maybe its a sign that unit tests are your favorite hammer. When to support your testin

3) Are your refactoring steps too big? (Is it actually a "rewrite"?) Or maybe its a sign that unit tests are your favorite hammer. When to support your testing methodology you have to say that shuffling a bit of code or structure around is probably a bad idea anyway because its a big change, you've gone off the deep end. For better or worse unit tests shackle your code in place. Maybe the "refactor" or "rewrite" is a good idea, maybe it isn't. But its not up to the unit tests to decide that. I've heard way too many times that the headaches introduced by unit testing are actually problems with my XYZ rather than a negative consequence of testing. If the tech you're trying to get me on board with comes with a long chain "you don't understand" and "you're doing [other thing] wrong"s after the fact, you've done a horrible job of explaining what you're selling in the first place. If I take this advice, and also practice TDD, I wind up in a situation where iteration is impossible. What were once nice tools to check that my code does what I expect, have suddenly locked me into a waterfall methodology. I suddenly have to know what I'm going to do before I do it, and when I change my mind changing the code significantly isn't an option either. Just admit that tests are not a panacea. They add significant cost to a codebase, and most of that time we accept that cost because it is more than made up for in improvements to code quality. Please don't pretend that all those costs are a good thing.