In another question, it was revealed that one of the pains with TDD is keeping the testing suite in sync with the codebase during and after refactoring.
Now, I'm a big fan of refactoring. I'm not going to give it up to do TDD. But I've also experienced the problems of tests written in such a way that minor refactoring leads to lots of test failures.
How do you avoid breaking tests when refactoring?
- Do you write the tests 'better'? If so, what should you look for?
- Do you avoid certain types of refactoring?
- Are there test-refactoring tools?
Edit: I wrote a new question that asked what I meant to ask (but kept this one as an interesting variant).
Best Answer
What you're trying to do is not really refactoring. With refactoring, by definition, you don't change what your software does, you change how it does it.
Start with all green tests (all pass), then make modifications "under the hood" (e.g. move a method from a derived class to base, extract a method, or encapsulate a Composite with a Builder, etc.). Your tests should still pass.
What you're describing seems to be not refactoring, but a redesign, which also augments the functionality of your software under test. TDD and refactoring (as I tried to define it here) are not in conflict. You can still refactor (green-green) and apply TDD (red-green) to develope the "delta" functionality.