Testing legacy systems may sound complex, difficult and time consuming. Depending on the approach you take it may become easier than you think.
What is a Legacy System
Firstly, what is a legacy system, what does it mean? It is a term used in the Software Industry that refers to an outdated application. Legacy systems are usually written using older version of libraries, outdated coding practices, running on old hardware etc. In reality many organisations have legacy systems. This begs the question ‘why have legacy systems’?
Over the course of time as applications evolve, teams may move onto new projects whilst also maintaining old projects. Teams may also build client applications to work on top of legacy system. This makes legacy systems a dependency of newer systems. Why might a team build applications to work with legacy systems? To re-use the functionality the legacy system provides. This is perhaps one of the most common reason which breed legacy systems.
Having legacy systems is not a bad thing. However if you don’t feel confident about your legacy systems, this can become a big risk to delivering any project which relies on the legacy system. When there is a lack of confidence in a legacy application, testing is the best way to increase confidence. How do you test a legacy system?
Testing Legacy Systems
There are a number of types of tests that you can write to try and enhance your confidence in testing legacy systems. You can write unit, integration or end to end tests but would that return any real value in confidence?
Writing unit tests may actually not be very easy. You may be working with code that is very difficult to read and understand. Integration tests on the may be a little more easier to write since they are not looking at the coding of individual classes but again you are subject to the mercy of the state of the legacy system. Would you feel comfortable writing tests using an older version of libraries?
What about continuous integration? By writing any form of low level test, you would also need to monitor the CI pipelines of the legacy system. You may end up inheriting more responsibility than the value of the legacy system.
Another problem may be the system itself. As it is a legacy system, it may be replaced therefore all your effort of writing unit and integration tests may lose their value completely.
How about end to end tests or more specifically writing Black box tests?
Testing Legacy Systems with Black Box Tests
Writing Black Box tests loosely translates into what I would call a consumer or customer test. A Black Box test would completely ignore the logic of the application and how it works but instead focus on testing the input and output of the application.
The purpose of the Black Box tests would be to see if the application ‘behaves’ the way you would expect it to behave. You can use these tests to measure a level of confidence of the application without ever having to touch the code. More so if the legacy is removed or replaced, the Black box tests would need to be updated. You do not need to understand or think about the CI solution for the legacy system as you can build and maintain your own.
Conclusion
Writing low level tests for a legacy system may lead to more issues than it can solve. You may quickly overburden yourself with having to learn old technology, practices and having to manage more projects. If the legacy system is dropped, the value of the tests would be lost.
I would say that the more efficient way to test a legacy system is to write a series of Black Box test that tell you if the legacy system behaves in the way you would expect it to behave. It might be impossible for you to know how the application is designed to behave but it would be possible to predict the expectation of the legacy system.
