Applying Working Effectively With Legacy Code

Having recently read “Working Effectively With Legacy Code” (WEWLC) my work provided me the oppertunity to put it into practice. I had been handed a small program to maintain : it has a few issues that needed fixing. The product is written in VB.NET, uses a mixture of module level functions and classes to acheive it’s aims. There is no clear design or documentation and it relies upon COM calls to an external API of a product that I do not have a licence for (and it would be expensive to obtain). It had no unit test coverage. By all definitions this is Legacy code.

To be fair the application did have a set of wrapper functions that were used to access the API.
The first stage was to put these methods into a class and use “Lean On The Compiler” to find where to create the class. Having done so I was able to add some methods to the class so that it provided a better abtraction from the COM API (the same three COM calls were being made in sequence across the App). Once I had these I was able to reduce a fair amount of duplication.

Having extracted a class that access the COM API (which I could not yet unit test) I was able to perform “Extract Interface”. Given that COM API’s are extensively interfaces they are very easy to mock (except that the interfaces are execisive wide). By mocking one of the COM interfaces I was able to re-implement the extracted interface. This finally allowed me to get some of the application under NUnit.

Eventually the bug turned out to be in the data access code – there was a remove method with an optional second parameter. The second parameter controls whether to remove the item from the underlying database.

By using the techniques in WEWLC I was able to get an unwieldy application at least partially under unit test. However I was not quite able to meet the stringent requirements of unit tests taking less than 0.01 seconds. In addition the policy of not touching the database in the unit test meant that I had not been able to find the given bug directly. I had managed to prove that the method that called it was otherwise working.

I can see WEWLC becoming a classic along the lines of Refactoring.
It provides the answers to the questions that would prevent most people from attempting to get their code under a test harness and thereby allows TDD to be used on non-greenfield projects.