How to cleanly unit test a custom ValueResolver ResolveCore(...) method

Question

I'm trying to unit test a custom ValueResolver (Automapper) but am running into problems because the method it forces me to override is not exposed directly in the custom object we must create. I override the protected method "ResolveCore" but the only public method exposed is "Resolve" which expects a complex "ResolutionResult" automapper object as it's input. In the vein of true unit testing I want to test this object / method in isolation to anything else and don't really want to go the route of firing up automapper with mappings to do this test. Likewise it's not possible to Mock "ResolutionResult" and it seems a very complex object to setup for each test (again requiring creation / association of other Automapper objects).

The only (less than ideal) solution I can come up with (and have seen suggested when Googling for a solution) is to stub a public method inside the class that exposes the protected overriden method. If we must go down this route then so be it, but has anyone else got a better solution that tests the method call in isolation doesn't require a modification of the object we are trying to test?

Example code:

public class CustomResolver : ValueResolver<Supplier, string>
{
    protected override string ResolveCore(Custom source)
    {
        return string.Format("{0} {1}", source.Name, source.Descripton);
    }

    public string UnitTestStub(Custom source)
    {
        return ResolveCore(source);
    }
}

Answer 1

I wouldn't place a public stub in your class. Instead, I'd just create a simple subclass in my unit test assembly that exposes the call I wanted to test:

public class TestCustomResolver : CustomResolver
{
    public string TestResolveCore(Custom source)
    {
        return this.ResolveCore(source);
    }
}

Some of this depends on the unit testing framework you're using too. For example, you could use the InternalsVisibleTo() attribute to expose your internals to your unit tests. However, I would lean towards a simple subclass in your unit tests.