Adding Unit Tests to code not designed for it

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 o开发者_StackOverflowf 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?

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.

I found Michael Feathers' Working Effectively with Legacy Code useful when researching this topic.

My experiences:

1. Implement a way for system (end to end) tests
2. When you add new functionality write system tests and design the new functionality with unit tests
3. When you change existing functionality write system tests beforehand
4. Do NOT try to rewrite existing modules for testing them with unit tests

This way you get unit tests for new functionality and create a (althought wide) security net for old functionality. Over time more and more parts of your system get system tests and (in percent) you get more coverage with unit tests. Redesigning old code just to get unit test coverage is to costly.

I'm with your lead developers. It's 1.2 million lines of code which means which means that there is PLENTY of room for error when testing and redesigning. Its not designed for UT so it would probably take a non-trivial effort to rewrite the code so that it can be tested. I'm sure unit testing would be very time consuming. Plus, it's an old product which presumably means many of the bugs have already been found and fixed. If it ain't broke, dont fix it. Wouldn't you rather move on to the more interesting aspects of the project than testing and refactoring old code?

That said, if I absolutely thought it needed to happen, I would probably just write the tests for the pieces I touch, as I touch them. If I dont touch them, I dont test them.