Does it make sense to write tests for legacy code when there is no time for a complete refactoring?
Posted
by
is4
on Programmers
See other posts from Programmers
or by is4
Published on 2014-02-06T07:15:14Z
Indexed on
2014/06/06
21:51 UTC
Read the original article
Hit count: 210
I usually try to follow the advice of the book Working Effectively with Legacy Code. I break dependencies, move parts of the code to @VisibleForTesting public static
methods and to new classes to make the code (or at least some part of it) testable. And I write tests to make sure that I don't break anything when I'm modifying or adding new functions.
A colleague says that I shouldn't do this. His reasoning:
- The original code might not work properly in the first place. And writing tests for it makes future fixes and modifications harder since devs have to understand and modify the tests too.
- If it's GUI code with some logic (~12 lines, 2-3 if/else block, for example), a test isn't worth the trouble since the code is too trivial to begin with.
- Similar bad patterns could exist in other parts of the codebase, too (which I haven't seen yet, I'm rather new); it will be easier to clean them all up in one big refactoring. Extracting out logic could undermine this future possibility.
Should I avoid extracting out testable parts and writing tests if we don't have time for complete refactoring? Is there any disadvantage to this that I should consider?
© Programmers or respective owner