How to Increase Unit Test Coverage of Legacy Code?

The article represents a time-tested approach on how to increase unit test coverage with legacy code. I shall try and answer following relevant questions in order to present the approach on increasing the test coverage of legacy applications (code).

What are some of the key challenges?

1. Leadership Buy-in: As soon as you start planning for writing unit tests on legacy applications, you come to realize that it won’t be very effective and smooth without the consideration of code refactoring. The reason being the fact that legacy code in many cases are found to have very high code complexity in terms of cyclomatic complexity and, familiar code smells such long classes, long methods etc. And, writing decent unit tests on top of such code won’t be very effective unless the refactoring is done. And, for refactoring, the most important thing is the time factor. Until leadership supports the initiative and agree to sponsor the releases with a bit lesser product features along with refactoring accompanied by unit tests, this is not going to be successful.
2. Team’s Readiness: Next to getting leadership buy-ins is getting team ready for refactoring and write unit tests. This requires following four important things to happen, all of which are equally challenging:
   1. Getting someone agreed to acquire business knowledge or, getting hold of business analysts (a tough task, I would say) around the legacy code such that when refactoring is done, business analysts should be able to point out various modules/UIs which will required to be tested.
   2. Getting team ready to write unit tests which may not be as simple as just writing unit tests. Mind you that the objective is to increase the code coverage/test coverage and this would require team to be ready to do code refactoring as well.
   3. Getting team together to acquire knowledge or, undergo training on code smells and associated code refactoring techniques
   4. Getting team together to acquire knowledge or, undergo training on best practices for unit tests
3. Organization Readiness: Getting other teams ready is also equally important. This is because, once the team starts focusing on writing unit tests, it would essentially mean that business features would not be coming out with as speed as done earlier. This would require entire organization to adjust with the fact that the focus is on reducing technical debt and thus, every team would have to plan for their releases accordingly. Even, business users buy-in is also important.
4. Development Practices: Once the team is ready on writing unit tests, another challenge would be to re-look at the development practices to accommodate unit test automation and code review. This is because the fruitful results of writing unit tests would only show up if there is nightly automation of entire suite of unit tests such that the alerts are raised if one or more unit tests break. Additionally, code review would help monitor the quality of unit tests written by the developers.
5. Tools & Frameworks: Once all is done, the remaining challenge would be to have tools & frameworks such as JUnit, NUnit or XUnit frameworks accommodated in development practice. Additionally, one would want to use test coverage tool to monitor the code/test coverage from time-to-time.

How to go about increasing the test coverage?

1. Team’s Training: As mentioned above, developers would be required to be trained on unit testing and related best practices. Some of the key concepts in relation with unit testing training are following:
   1. Best practices
   2. Unit testing naming
   3. Mocking
2. Development Practices: The development practice would require to accommodate the test automation and code review practice. Additionally, the development practice would also need adjustment in estimation. Many a times, developers complain that they do not write the unit tests due to lack of time. Thus, during planning phase, someone would need to dedicate additional time for writing unit tests. Once all is in place, developers may want to adopt following technique:
   1. Start with baby steps. Write unit tests for any new methods introduced in the class.
   2. Look out for refactoring opportunities and introduce new unit tests for existing code if the change needed is small enough.
3. Tools & Frameworks: One would be required to work with XUnit testing framework such as JUnit, NUnit etc.
4. Monitoring: It is equally important to use the code coverage tool to check if developers are able to increase the code coverage over a period of time. Tools such as Sonar include various plugins for different languages and could be used for monitoring/tracking the test coverage.

[adsenseyu1]