Shad, a fellow developer and good friend, and I were hiking a great new loop I found in Mt. Diablo State Park the other day and after solving the rest of the world’s problems we eventually came around to talking about things that were driving us nuts in our current projects. We both had recently found ourselves with code that was initially a quick and dirty library with a “Button 1″ interface. ( You know the type, programmer’s make them. They have a single command button on them and you click them and then they do stuff..and never notify you when they are done, and don’t resize and a host of other things that a normal UI should have ). These “Button 1″ quick and dirty apps have a nasty habit of turning themselves into indispensible tools for production/operations stuff.
The big problem we were both having was that while the apps were decent enough for their initial use we were being asked to extend them and both of us wanted to do some refactoring of the application before we released them into the wild. The best approach for this sort of thing is to develop unit tests so that, once refactored, we could be sure that we hadn’t broken anything important.
The biggest problem with dropping unit testing into an application after the fact is that sometimes you run into problems where you have to refactor just to get the unit tests access to all of the routines that you want to test. This isn’t an ideal situation, as you quickly end up wondering if you are breaking things just trying to get some unit tests built that are supposed to ensure you aren’t breaking anything. So you start wondering if instead of refactoring if you simply make functions that wrap your private functions and expose the behaviour might be the answer, pretty soon you have stuff everywhere and you wonder which is your testing code and which is your unit testing code to make all of this possible. Madness.
As we dropped off of the fire trail back into a heavily wooded area with a nice creek, it came up in conversation that perhaps partial classes were the way to go. If you haven’t used c# partial classes, you will. You can write class code in multiple files and yet at compile time it is assembled into a single logical unit. Several days later I had some free time and was able to verify that this would indeed work, I could drop all of my unit testing code into a single file that would provide all of the unit testing logic and wouldn’t muddy up the existing class. Furthermore, with a couple conditional complilation statements I could get rid of all of the unit testing code from the final release of the new library.
This is obviously not the approach you want to take if you can avoid it. It is arguable that you do not want your classes invaded in such a way for the purposes of unit testing. This is something you can work around if you use unit testing from the beginning, but what if you inherit a project and it doesn’t have any unit test capabilities built into it? What if the way that the classes are structured make unit testing pieces of the application difficult? Do you just plow forward and hope for the best? I hope not, and hopefully this stop gap measure to get unit tests built into the classes so that you can test existing functionality is the way to go. With these “nunit partials” in place you should be able to then start refactoring the rest of the application to be a little bit better structured for unit tests without having to risk dropping anything.