Looking to the future isn't the only plus of writing unit tests for old code. This afternoon I was finishing up unit tests on my animation class and I found a nice bug around trying to load corrupt animations. I never ran into the bug while coding my last game but this is the type of bug that you can hit in the future and spend hours trying to debug.
I also finished refactoring my manager classes to accept a mutex object in the constructor instead of creating platform specific manager classes. Once again I had tests ready to go after my refactoring was done that I could run to make sure I hadn't messed something up by accident.
I should also clarify that you don't really need to follow pure test driven methods where you create the test before you create the object. A lot of people find that technique ideal but I think you still gain a lot by having unit tests after the fact.
Thanks a lot for writing about the unit tests - I had never been exposed to them before, and it is an interesting method of verification. I have a couple of questions though:
1. Is the test supposed to look for exceptional cases or should it be testing functionality of the class?
2. How detailed should the test be? I have a CEntity class which is the base class for all game objects which literally has about one hundred methods (implying lots of functionality). How in the world do you devise one hundred or more tests for a single class?
I suppose part of this will come with experience in testing, but I have over 200 classes in my project - it just seems mind boggling that this type of testing gets added to libraries after the fact.
Anyways, thanks again for the post. Have you considered writing a short article for gamedev on the topic? I think software engineering is a field that is under represented by the current set of articles. Give it some thought...