Testing Legacy Code
Testing Legacy Code
The issue
If you have never had to deal with legacy code, count yourself lucky and know that it is coming :)
Some of you may be permanently stuck in maintenance development. Your life is legacy code :(
We want to either prevent legacy code from happening, or fight it back to the depths from which it came
Working on that project is no fun; the code is a mess, and you want to find whoever wrote it and find out what they were thinking when they wrote it.
At some point in your career, you have been or will be that person to someone else
Code without tests is bad code. It doesn’t matter how well written it is; it doesn’t matter how pretty or object-oriented or well-encapsulated it is. With tests, we can change the behavior of our code quickly and verifiably. Without them, we really don’t know if our code is getting better or worse. To me, legacy code is simply code without tests!
– Michael C. Feathers, Working Effectively with Legacy Code
Why does code go bad?
In short, code goes bad because we are afraid to change it! Chances are, you are not the first person that has needed to make a change in this code.
So, this is not the code that was written by a developer doing his or her best to write good code. This code was written by many developers.
When we have to change it, we generally try to change the code as little as possible to get the requested update working. After all, we don't want to force ourselves or QA to do a full regression test because we refactored the whole thing, do we?
Over time, making these small changes and being afraid to modify the structure and architectural decisions of the original developer causes severe code rot. Soon, the code will have massive conditional statements and methods that no longer fit on the page. The class containing the code will grow to tens of methods and the file will be thousands of lines long
When does a project become legacy?
This is a question that is answered by many people in many different ways. Generally, an application has become legacy when no one wants to work on it anymore :o
In the beginning, applications are built with a small and defined purpose. Over time, the scope and breadth of a system may grow beyond its original intent. When any change to the application causes the developer to work against what the application was designed for, it will cause friction.
The application design is not simply changed because of the fear a developer might have that the application will break. So, more and more cruft is added to the system! Cruft, in software, is any code that is unnecessary or needlessly complex.
Making a system flexible is not as hard as you might think. Following the SOLID principles will help to produce a maintainable and flexible system.
Even with a flexible system, it takes discipline and determination to maintain a standard of recognizing and fixing friction in the application.
Last updated