Search code examples
.netunit-testingmockingendeca

Unit Testing in .Net with Endeca Objects


Most or all of Endeca's objects have internal constructors. I'm working on a good project that lacks great test coverage around the Endeca API, are there any good strategies to unit testing the interactions with Endeca?

So far the best we have is kind of a poor man's adapter pattern:

public class DimValue : IDimValue
{
    public DimValue(Dimension dim, DimVal dimValue)
    {
        Dimension = dim;
        Value = dimValue;
    }

    public virtual bool IsNavigable()
    {
        return Value.IsNavigable();
    }

    public virtual long Id()
    {
        return Value.Id;
    }

    // and so on...
}

We can then mock our own type, DimValue. Is this the best way to keep their API as testable as can be? Or is there another method that is preferred to this?


Solution

  • If you are trying to test your usage of the API, then I would recommend the approach you mentioned.

    It is a good design goal to be writing your application built on your own abstractions, not someone else's. The adapter layer gives you a chance to translate the API into a domain language your developers are more comfortable with and gives you the freedom to change technologies later if the product you are using falls short in some way.

    Resharper had a great feature for creating wrapper classes. Create a class, add a member that is the type you want to wrap.. then trigger the generate delegates refactoring. Pick 'all public' and there you go.. one wrapped class.

    Only expose the subset of their functionality that you are actually using. In your wrapping code, provide interfaces so you can mock.

    If you are testing Endeca's API as some form of regression suite so that you can more easily accept new released of their API, then I would just write tests at a more 'acceptance' level; exercising the API they give you. But again, only test the ways you are actually using their API.

    I would do the above approach, however...

    TypeMock will let you mock classes without interfaces, so that may allow another approach.

    Hope this helps.