Unit Testing in .Net with Endeca Objects

Question

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?

Answer 1

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.

Answer 2

Most Endeca classes are concrete so it is difficult to do unit testing, in our last project we must defined ourselves an abstract layer, exactly it was a facade layer between our own code and Endeca API e.g. IEndecaQuery. With that abstraction layer we could do a test quickly without any real Endeca access, you know openning an Endeca connection will cost you several seconds each time. It was lots of work to implement all necessary Endeca fake objects. Our application was an ecommerce site and we utilized Endeca for all product listing, searching funtions.