November 29, 2014
Automated Refactoring Tools Don't Exempt Us From Re-testingYou can find some pretty dodgy advice out there on software development.
This morning, I had an email waiting for me in my inbox from someone who'd attended Codemanship courses, with a worrying question about the discipline of refactoring.
Refactoring legacy code, certainly at the start, can be difficult because of the lack of automated regression tests. She had heard in a presentation at a conference that if you use an automated refactoring tool to perform a refactoring, you don't need to run the tests afterwards.
This is troubling advice. It places more faith in such tools than I believe, from experience, is warranted. They don't always work quite as we expect they should. For sure, using an automated refactoring is no guarantee that behaviour is preserved.
It's also the case that the set of automated refactorings these tools offer - without exception at the moment - do not get us seeamlessly from A to B all of the time without the need for us to do some refactoring by hand. (There's an area of research, by the way, that I think would have much value. I'd love to be able to do refactoring completely using automated tools. It would be quicker and safer.)
So, given that these tools aren't 100% reliable, and given that they don't enable 100% automated refactoring, the need to retest our code is not significantly diminished by their use.
In practice, when the code we want to refactor isn't (sufficiently) covered by automated tests, we have two sensible choices:
1. Write some automated tests for it that will give us enough confidence we didn't break the software
2. Test it manually, if the current design (e.g., because of dependency issues that can only be resolved by refactoring) makes automating tests too difficult
Posted 3 weeks, 2 days ago on November 29, 2014