Here's the problem. You have written unit tests, both to help you understand your design and to find bugs. In due time, you refactor your code, which causes tests to break. The interface they communicate with has changed, so they must change to match. Are there reasonable alternatives to RefactorBrokenUnitTests??
There's a bit of detailed discussion on DeletingBrokenUnitTests.
If you always RefactorBrokenUnitTests, lots of good things happen:
- If you need to change the interface that the tests use, there are probably interface changes in the using code as well. Might as well fix them all.
- Removing tests from the system can only decrease reliability. Leaving them in maintains reliability.
- Removing tests from the system may save time right now. However, fewer tests in the system will slow down development - perhaps only by a little, but it will slow you down through increased debugging and decreased clarity. Leaving the tests in keeps your speed where it is.
Therefore, when you refactor,
RefactorBrokenUnitTests.
Can you give a specific example of RefactorBrokenUnitTests? This advice needs more detail before I can get an adequate feel for what it means in practice:
- What kinds of refactorings are done?
- How often are the refactorings made to the test code, and how often are they made to the product code in support of tests?
- How much test support code might I expect to end up with? (Either in the test code or the product code.)
- Do refactorings insulate against further code changes, either by design or emergently?
See the first example in
MovingBrokenUnitTests. My gut feel is that, for that case,
RefactorBrokenUnitTests and
MovingBrokenUnitTests really mean much the same thing. That is, in both cases you'd end up using a parser.
How often are they so similar? Not always, of course. Still, although RefactorBrokenUnitTests is strictly more general, how often does it amount to finding a pre-existing stable interface and "promoting" tests there? --BrianMarick
See MovingBrokenUnitTests, DeletingBrokenUnitTests, TwoYearItch.