I recently posted a short blog entry on using TDD practices when working with Legacy code. In a comment to that post Mike Kelly raised a couple of questions/issues that I want to address.

Here is part of the comment Mike made:

One question I have, is how to apply atomic TDD methods, modules, to code that is not really designed for TDD?
For instance, if you had to support VB6, or COBOL, or some other language... not to mention scoping visibility...
I struggle at times just writing TDD code for my own code! I'd be interested to hear more on this topic...

TDD principles dictate that tests should be "Atomic", that is they should apply to a very granular area of code in the system under test. So how would we implement TDD in a legacy system especially one that TDD had never been used with before?

In a word, Mock Objects. Mocks become very valuable when you have to work with a system "at arms length" from the code. That being said, there are some issues with this approach. You are adding a layer of abstraction from the actual code under test, and if you are not careful you end up with test code that is too tightly coupled to the code you are trying to test which makes any refactoring difficult.

Mocks are not the end all be all by any means. In the .NET world it is actually fairly easy to add TDD support for languages like VB6 after the fact. Scope is certainly an issue. But since VB6 can call .NET assemblies via COM Interop you can fairly quickly put together a test class inside of the scope of a VB6 application. If there is any interest I can blog some examples on this with a project that I recently added TDD practices to.

I have not worked with any variant of COBOL since the early 80's when I worked on an IBM 360 system. So I can't comment directly on COBOL, but I would imagine Mocks would help here as well.

Next post, Mocks!

Cheers,

Robert Porter

Some resource links of interest on this topic.

Applying Test Driven Development to an existing application. - Eric Hexter's Blog

Test Driven Development, a Portable Methodology - Nancy Corbett

Why and When to Use Mock Objects - 

Jeremy D. Miller