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?

Answer 1

You have two options here:

1. 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.
2. 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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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)