When dealing with code defects, a rule advocated in the agile community states that you should write a failing unit test before you start fixing a bug or refactoring.
What if, however, the code design is untestable at all? It might be too difficult to write unit test for the existing legacy code. Is there any value in 100 lines of unit test code?
Unless the code is written elegantly with SOLID principles, writing unit tests is not easy, especially behavioral tests. Introducing an integration test might be the only option, but it's also not an easy option (ie out of process calls, etc)
As a result, developers when taking into consideration the time and the effort associated with writing unit test(s) before fixing a defect - often decide to write neither unit tests nor do refactoring.
There should, however, be a middle ground.
There are different types of refactoring. Some major infrastructure or framework change, where thousands of lines of code are being modified - is considered large refactoring that should be avoided when there is no test harness around it.
But what if it is just something minor? For example, a simple Extract Method refactoring to split a long method, combined with moving a new method to another class. It shouldn't be too complicated. Tools like #resharper are there to help. Along the way, a dependency injection can be introduced to a new class as well.
As a result, a testable unit is created. Some short and comprehensive unit tests could be easily written for this method - unit tests that fail. Now, the original defect can be fixed.
There shouldn't be too much risk in this simple refactoring. Moreover, this method could be reused in other parts of the system.
And remember the boy scouts' rule: "Always leave the playground cleaner than you found it." (see Uncle Bob's article)
Last revised: 20 Jun, 2012 03:26 AM