Mocking concrete object properties with no setter

Question

I'm testing a service that interfaces with a third-party system. The method exposed by the API returns objects that look something like this:

public class Thing
{
    public string Name { get {...} }
    public string Description { get {...} }

    public Thing(string someUri)
    {
        /* Do some secret internal stuff and
           populate all my properties. */
    }
}

I need to mock these properties in order to test that my service behaves correctly according to the objects returned.

The objects are instances of a concrete class that does not implement any interfaces that I can mock. The backing fields of these properties are set in the constructor of Thing, which takes a URI, goes off and fetches the object in some tightly-coupled third-party system and presumably sets the backing fields directly.

All of this means that I have no way to mock the properties - I can't set them directly, I can't mock an interface and I can't mock out the constructor dependencies and set the properties that way (which would diminish the usefulness of my tests anyway).

Is there any way around this?

score 1 · Answer 1 · answered Mar 05 '14 at 13:59

1

You can use Shims (build into visual studio) to fake a Thing

http://msdn.microsoft.com/en-us/library/hh549175.aspx

answered Mar 05 '14 at 13:59

Jonas Jämtberg

573
2
6

Note that Fakes and Shims require Visual Studio Premium or Ultimate. Another, cheaper option is [TypeMock](http://www.typemock.com/). – Bart van Nierop Mar 05 '14 at 14:08

score 1 · Accepted Answer · answered Mar 05 '14 at 14:08

Assuming you are using VS2012.2 or VS2013 in either Premium or Ultimate Edition, shims should get you what you need. They allow for "shimming" properties and constructors, ideally only for scenarios like the one you find yourself in (third-party library that doesn't use interfaces).

After adding a Fakes assembly for your library in your unit test project, you'd do something like this in your unit test:

using (ShimsContext.Create())
{
    ShimThing.ConstructorString = (@this, value) => {
        var shim = new ShimThing(@this) {
            NameGet = () => "Your Desired Name",
            DescriptionGet = () => "Your Desired Description"
        };
    };

    //do whatever you need to do that creates a Thing object
}

I wrote this example without actually trying it out, so the syntax of the ShimThing constructor might be slightly off.

score 1 · Answer 3 · answered Mar 05 '14 at 14:33

1

You could just wrap the Thing -- this probably isn't the answer you're looking for because it will involve changes to the application code to support your unit testing, but it will result in a more loosely coupled code base and might make your life easier in the long run.

Create a ThingWrapper class that takes a Thing as a constructor argument and whose properties call the getters on the wrapped Thing instance. You can then

mark these properties as virtual and mock the wrapper directly (less code)
or have the wrapper implement an interface code against that interface (probably better).

Hope this helps, sorry if I'm just stating the obvious :/

answered Mar 05 '14 at 14:33

Joe Taylor

2,145
1
19
35

Thanks for your answer Joe - unfortunately, though, what may not be obvious from my question is that the service under test is effectively already the middle-tier wrapper you're describing! – Ant P Mar 05 '14 at 14:40
Fair enough. If it's the abstraction layer itself then it may be not be worth unit testing; a BDD type integration test might be more appropriate. I'm a little dubious about Fakes, not least because they're limited for VS Premium/Ultimate Edition. Some interesting discussion here: http://stackoverflow.com/a/11654698/332868 – Joe Taylor Mar 05 '14 at 14:46

Mocking concrete object properties with no setter

3 Answers3