This morning I made a small but important change to a chunk of code that our entire Silverlight application uses. This code, lets call it the Manager, facilitates every work flow through the application. The code change to the Manager amounts to deleting some unused code, changing some types, and some small tweaks to how new screens are called. On the surface the actual lines of code changed appeared to be very simple, but I was nervous I would break something since this is a fundamental piece of code. Everything uses the Manager.
Code can have subtle and dangerous dependencies. Even when one is the author (as I am in this case), one cannot be completely sure of the consequences of a code change in a sufficiently complex system. This is where unit tests come to the rescue.
I was able to execute my suite of unit tests, and after a successful report I ran through a few regressions with live data. Everything works. And I commited the code to our repository with a high level of confidence.
If something had broken I would have fixed it, and then written a unit test to check for the condition in the future.
Unit tests are a pain to write, but they sure do have a big payoff.
