Rarely do legacy systems have any sort of automated testing in place. Usually, all testing has been completed manually on the project. And when this is the case there often isn’t an obvious spot in the solution to add a unit test.
Adding tests to an existing project can be extremely painful. There is a reason existing developers didn’t add tests. They probably wanted to, but couldn’t figure out how to easily make it work. But if you want to be as effective as possible with your legacy system, you are going to have to put some testing in place.
There are two types of automated tests you should try against the legacy system. The first is unit tests, where pieces of code are tested in isolation. The second type is integration tests, where everything from the top to the bottom is tested.
Adding unit tests will help you quickly access a project from a few different dimensions (testability, coupling, etc.). With more insight into the system, you’ll have a better understanding of what you are up against as you attempt to wrangle your legacy solution.
Adding unit tests also gives you an idea of how hard it will be to add unit tests to the solution. The previous statement seems silly but forcing yourself to add a unit test will force you to fully feel the pain of adding a test to the solution. In some cases, the “strangle” technique is a good way to get your system in shape. Regardless of how you do it, the ability to add unit tests is essential.
Adding unit tests will also expose how coupled the system is currently. A highly-coupled system makes adding unit tests almost impossible. But if you can tear the system apart into pieces and write some unit tests for them, the coupling might not be that bad.
Adding integration tests should be a little easier than unit tests in a legacy system. Depending on the situation, you might be able to get away with adding only integration tests.
Adding tests in a legacy system isn’t easy, but it might be the best way to find out what you are up against.