Mock .NET classes using wrapper classes

Question

I have a class that takes a MethodInfo instance and extracts some information from it, but I would like to mock this class. At the moment it is difficult because it takes a MethodInfo, so my plan was to create a wrapper for the MethodInfo class and implement an interface on it. For example:

public interface IMethodInfo
{
    string Name { get; }
}

public class MethodInfoProxy : IMethodInfo
{
    private readonly MethodInfo _method;
    public MethodInfoProxy(MethodInfo method)
    {
        _method = method;
    }

    public string Name { get { return _method.Name; } }
}

public class MyClass
{
    public MyClass(IMethodInfo method)
    {
        ...
    }
}

Another example would be the File.Exists method. The thought would be to create a IFile.Exists and put it on a FileProxy class that would simply delegate to File.Exists.

As I'm new to the whole unit testing world I would like to know if this would be considered a good approach to take?

I do not really see why the fact that it takes a MethodInfo object poses a problem in mocking the class? — wendazhou, Mar 27 '11 at 06:51
I've just noticed that MethodInfo uses the _MethodInfo interface which I could use. But, what if I wanted to mock the Directory.Exists or File.Exists behaviour? If I created a wrapper class for each class/method/property I need, then I would guess it would make it easier when unit testing my classes. — MotoSV, Mar 27 '11 at 06:56

sheikhjabootie · Accepted Answer · 2011-03-28T09:15:39.877

You have two options here:

Use a mocking framework like Microsoft Moles or TypeMock Isolator that can mock static and sealed classes. This is great because you don't end up changing your code just to isolate the code under test from its dependencies.
Defining interfaces for behaviours that you want to mock, and then creating a default implementation that wraps a static call, or other difficult-to-test api. This is the approach you've suggested and one that I've used a lot. The key thing, when defining these interfaces is to pass the real/mock implementation of the interface into the test class via some form of dependency injection - usually constructor injection. Some people make the mistake of constructing the object within the class being tested and that makes it impossible to test. A good rule of thumb is that when you see objects being constructed in your business code, then that is a code smell - not always a bad thing, but definitely something to view with suspicion. There's a great video about this stuff: The Clean Code Talks - "Global State and Singletons".

There's a bit of a religious war between those who think testing shouldn't change the code and those that think it should. Dependency injection, which is essential if you are going to mock by creating interfaces, leads to code with high cohesion and loose coupling and an intuitive API. But the other approach isn't precluded from these benefits - it's just not so automatic.

I had a look at Moles and I think it could be useful. For the MethodInfo problem I could use the _MethodInfo interface, but for things such as File.Exists I am now debating whether to use Moles or to create a IFileSystem interface and class. The interface approach helps with de-coupling, but this could be ultimately be too much work for too small a benefit (at the moment anyway). I will have to think about this. — MotoSV, Mar 28 '11 at 07:13
One of they downsides of the interface approach is that you end up with a lot of interfaces. Worse, the visual studio "Go to declaration" and other navigational aides go to the interface and not the implementation code, so analyzing new code can get a bit impaired. Moles is great, but tends to encourage the use of static code - which is the bane of automated testing. — sheikhjabootie, Mar 28 '11 at 09:19

score 1 · Answer 2 · answered Mar 27 '11 at 14:00

I recommend trying to pull the dependencies out of the class - instead of supplying a MethodInfo (or a proxy), just supply the Name.

When that isn't practical, you can either write proxy classes that use an adapter interface (as you've suggested) or use a black-magic tool like TypeMock or Moles (just kidding about the black magic part: I just don't have any experience with them).

If you plan to use the proxy approach, be sure to take a look at the SystemWrapper library, which already handles about twenty classes from the .NET framwork.

score 0 · Answer 3 · answered Aug 27 '13 at 01:08

0

For faster creating of wrapper classes, you can use one of the Scaffold code generator I created.

https://www.nuget.org/packages/Digitrish.WrapperGenerator/

This will generate Interface that you can use to any mocking framework and concrete wrapper class for the real implementation.

answered Aug 27 '13 at 01:08

Francis

299
3
2

Could you share the source or documentation? – Chris Jensen Apr 25 '22 at 10:45

score 0 · Answer 4 · answered Mar 27 '11 at 07:01

You could create a wrapper around each of the class that you use but it would be extremely expensive. It's better to use a mocking framework such as the moles framework by Microsoft http://research.microsoft.com/en-us/projects/pex/ which can also stub out static methods.

score 0 · Answer 5 · edited May 23 '17 at 10:29

A Mock class (or a fake class) would be a class you make to satisfy dependencies and make your test more deterministic by ruling out problems in your dependencies.

public interface IMethodInfo
{
    string Name { get; }
}

Your mock class:

FakeMethodInfo : IMethodInfo
{
 string Name {get {return "FakeMethod";}}
}

Now, in your unit test, pass the FakeMethodInfo class where you need an IMethodInfo.

The whole purpose is that you know FakeMethodInfo just returns a string so if something fails, it is not the problem.

Don't know what context MethodInfo has in your program. A better example would be

interface IUser
{
 string UserName {get;}
}

If it were implemented in a class you would get the actual username from a data base.

Now, if you make a fake one, and pass it around, you kinda simulate a user logged in without a real user, and you rule out that any problem has to do with `IUser.

See this large answer I posted on why you would use mocking. And an example with Moq.:

Difference between Dependency Injection and Mocking framework (Ninject vs RhinoMock or Moq)

Mock .NET classes using wrapper classes

5 Answers5