Adding Unit Tests to code not designed for it

Question

At work, we have a three-tier product. There is a client application which the users use and it queries data from a server which forwards those requests to a SQL database. We don't allow the client to have direct access to the SQL server.

The client product is what I'm wanting to unit test, but it has over 1.2 million lines of C# code and is a very old product. It was not designed with unit testing in mind and the lead developers for this product are generally opposed to unit testing mostly because of risk vs reward concerns, as well as how redesign would be required to reduce the amount of mocking that would need to be done. The redesign of these core, low-level client libraries and objects also has them concerned.

My philosophy is to certainly never neglect unit testing (because we'll always be too busy for it, and it'll always seem risky, and thus will never ever get done) and take an iterative approach to implementing unit tests.

I'm interested in hearing solutions to this situation. I'm sure many of you have encountered the situation of having to add unit testing into existing infrastructure. How could unit tests be added iteratively into the code base without hindering productivity and release cycles?

Answer 1

In situations like this (and we've in fact been undergoing the same process with an old webforms to MVC transition) is to simply start testing new code. Over time, eventually that old code will be rewritten or refactored.

Before 'new' code is considered valid, it must be unit tested and code reviewed. Over time, eventually you will find that more and more of your solution is now under test, and less and less old code is being called.