Question

I’ve got some code that performs some legacy ‘database’ operation and then processes the result. I want to write a unit test that checks the method that calls the legacy code without interacting with the ‘database’.

My code looks something like this:

    public static bool CallRoutine(LegacySession session, /* routine params*/)
    {
        try
        {
            LegacyRoutine routine = session.CreateRoutine(/* routine params */);

            routine.Call();

            // Process result

        }
        catch (LegacyException ex)
        {
            // Perform error handling
        }
    }

Were this all my code, I would create interfaces that the LegacySession and LegacyRoutine implement and then write unit tests that use mock implementations of those interfaces using MOQ or something similar. The problem is that I don’t have access to the code for LegacyRoutine or LegacySession so I can’t make them implement an interface.

Any ideas about how I could do this without changing the production code too much?

Answer 1

If you can’t access LegacyRoutine (i’m guessing it’s in a referenced DLL), why not just create a wrapper for it, then flick on/off different implementations:

public interface ILegacyWrapper
{
   ILegacyRoutine CreateRoutine(); 
   // etc etc
}

public interface ILegacyRoutine
{
   // put members of LegacyRoutine
}

Know what i mean? Just mock everything out into wrappers/interfaces.

Then you could go:

ILegacyRoutine routine = session.CreateRoutine(/* routine params */)

Where session would be declared as an ILegacyWrapper, but implemented with a mock concrete.

Also, it goes without saying (but i’ll say it anyway), you should consider a DI framework to make your life simpler. Otherwise you’ll end with IFoo foo = new Foo() (hard-coded injection) all over the place.

StructureMap is my DI poison of choice.

HTH