I’ve made a fairly significant change to THTMLWriter. (Even if you aren’t a use of THTMLWriter, please keep reading, there’s a valuable lesson at the end.)
What Did I Do?
I created an interface – IHTMLWriter – which simply lists the public interface of the class – and then had THTMLWriter implement that interface. Not a big deal. The big deal is that now the Fluent Interface is done with the IHTMLWriter interface instead of the class itself. This shouldn’t be a big deal if you are using the class – you merely need to change the variable declaration to IHTMLWriter, and remove any code that destroys/frees the class you may have created.
Why did I do this? Well, I have to confess that it was partly because I could. But I also think that in general, interfaces are better to deal with, particularly with the fluent interface. I’ve noticed that interfaces appear to be the typical way that such things are implemented. In addition, an interface limits the scope available to the consumer of a class. If you can only use a class via the interface, I as the developer can decouple the implementation from the interface – something that is always good. Plus, if one of you fine people feels like there is a better way to crank out HTML, now you can do it, too, using the same interface.
The Valuable Lesson
Here’s the part that you all need to read: I was able to make this rather large change with a lot of confidence because I had a pretty extensive set of unit tests to back me up.
The initial change – creating the IHTMLWriter interface and changing the class to implement and use it – broke everything. No test would pass, and the test program did nothing but raise access violations. So, of course, I went to work and fixed things up. I had to change a little architecture, alter the way a few things were done, and generally fix things up.
All of my debugging was done on the test project. It provided a perfect, simple reproduction of the bugs. The unit tests enabled me to easily step through simple examples and find the places where the bugs were and where things weren’t working right. And eventually the tests all “turned green”.
And let me tell you, turning green is sweet! First, it feels really good. I kept running the tests and watching that little green bar slide across because it felt great. Why did it feel great? Because I knew that my changes were complete and because I had confidence that things were all working as they were supposed to. The only way that was possible was because of the existence of the unit tests. Without them, I’d never really ever be sure that things were back to normal and working.
Time Well Spent
So the unit tests allowed me to forge ahead with confidence, provided me with a useful and powerful vehicle for testing and debugging my changes, ensured that I would know when I was done, and enabled me to prove that things were working as they should – all while making a fairly substantial change to a fairly complex code library.
And some people say they don’t have the time to write unit tests. I say you don’t have the time not to.