Question

I have a situation where in MS Dynamics Crm it returns some objects using sealed classes and readonly properties (I can only presume using internal constructors or internal property sets). And these guys don’t inherit from an interface I can use. Obviously, if I had control over this code I would have a lot more control, but because it’s in the underlying MS Dynamics framework I’m a bit stuck.

The class I’d like to mock/override is called AliasedValue. The reason I want to mock it is I’m trying to simulate a call to dynamics and want to pretend I’m getting returned some Aliased Values.

So here’s the scenario, I want to create a sample entity that Dynamics will return… something like this:

var new_entity = new Entity("new_entity")
    {
        Attributes = new AttributeCollection
            {
                {"new_name", "BR"},
                {"createdon", DateTime.Now.AddDays(-1).Date},
                {"new_field", "My field"},
                {"new_contact", new AliasedValue {*****} }
            }
    };

So I am referencing a “contact” entity (in real time this comes back as an AliasedValue). While testing I want to make sure my code handles certain values that might come back in this field (e.g. it knows how to deal with an aliased value, and that if no linked contact is returned it doesn’t blow up, etc etc).

So if you’ve clicked on the link to AliasedValue you’ll notice the properties are read only… so I can’t set up test data…

Next up, I was going to create my own class and override the whole thing… but it’s sealed…

And on top of this, as you probably have guessed, Moq doesn’t like trying to mock a sealed class.

I’ve read I’ll need to purchase some “better” mocking framework to do this, but I really don’t want to have to fork out some extra money just to get around this 1 thing.

Anyone got a nice neat little solution for me to get around this?

Update for Clarification

---

A sample of how this is returned is as follows. I have a service which will be mocked to return the above object. Or what it actually returns is a collection containing the above object. So this is like so:

var service = new Mock<IOrganizationService>();
service
    .Setup(s => s.RetrieveMultiple(null))
    .Returns(new EntityCollection (new List<Entity> {new_entity}));

This is great, I can return the above entity and do what I want with it. So, after I have created the above entity and I return it via my mocked service I get the above in my “EntityCollection”. And once I have my entity I access the property as follows:

var aliasedContact = (AliasedValue)new_entity.Attributes["new_contact"];

Maybe I’m being silly but I can’t quite get how the answer (by Lunivore) will solve this… (adding a comment to get feedback…)

Answer 1

Abstract yourself from third-party libraries by adding an adapter class that’s so simple, you could test it by inspection. Rather than extending your target class, just compose your new class over the top of it. It can have the same names of methods, the same properties, etc. (though it doesn’t have to) – it just delegates to the sealed class.

If you have one class which returns your sealed class, wrap them both. So it might look like this:

var crmWrapper = new MSDynamicsCrmWrapper(_myMsDynamicsCrm);
var entityWrapper = crmWrapper.AliasedValue(url);

and the crmWrapper will do:

public EntityWrapper AliasedValue(Url url) 
{
    var entity = delegateCrm.AliasedValue(url);
    return new EntityWrapper(entity);
}

Simple. You only need to delegate those methods you’re actually using.

Not only does this allow you to mock the class out, but it gives you control if, say, the next version of MS Dynamics changes the API slightly, or there turns out to be weird behavior or poor performance. Also, you’re narrowing down the API to the bits of it that you’re actually using, so the code may even be easier to maintain.

There’s nothing in computing that another layer of abstraction won’t solve…