"Legacy code. The phrase strikes disgust in the hearts of programmers. It conjures images of slogging through a murky swamp of tangled undergrowth with leaches beneath and stinging flies above. It conjures odors of murk, slime, stagnancy, and offal. Although our first joy of programming may have been intense, the misery of dealing with legacy code is often sufficient to extinguish that flame."
– Michael C. Feathers, Working Effectively with Legacy Code
This chapter explores the following topics:
- Understanding the legacy code
- Working with testing impediments
- Exploring PowerMock
- Designing for testability with Mockito and PowerMock
The term legacy is frequently used as a slang to describe a complex code, which is difficult to understand, rigid, fragile in nature, and almost impossible to enhance.
But Michael Feathers, author of the legacy code refactoring book Working Effectively with Legacy Code, defines that any code with no automated unit tests is a legacy code. A piece of code could be well written, follow coding guidelines, easy to understand, clean, loosely coupled, and very easy to extend, but if it doesn't have automated unit tests, it is a legacy code.
Usually, fixing bugs or adding new features to a legacy project is very difficult compared to doing the same to a greenfield project. In legacy code, either automated unit tests do not exist or very few tests are written; the code is not designed for testability.
Winston Churchill said, "We make a living by what we get, but we make a life by what we give."
We inherit legacy code from someone else, it could come from a very old project, from another team that cannot maintain the code, or it could be acquired from another company; but it is our duty to improve the quality.
Unit tests give us some level of assurance that our code is doing what the code is expected to do and allow us to change the code quickly and verify the change faster.
In general, legacy code is not testable and requires code structure change (refactoring) to make it testable, but the dilemma is, most of the time, the legacy system is so crucial to the business that no one dares to touch the code. It makes no sense to modify an existing crucial module unless something is seriously wrong. Stalemate! You cannot refactor code unless you have the automated test suite, because without tests, you have no idea whether you've changed or broken the system, and you cannot write tests, as the code needs refactoring.
Sometimes, it feels like legacy code, even with unit tests, is hard to understand, maintain, and enhance. We need to be careful to make our tests especially readable and to avoid close coupling with the actual implementation details.
To learn more about legacy code, you can read the legacy code Bible—Working Effectively with Legacy code, Michael Feathers. The following is the URL to the book:
http://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052