views:

548

answers:

3

I am pretty new to use moq. I am into creating some unit test case to HttpModule and everything works fine until I hit a static property as follows

this.applicationPath = (HttpRuntime.AppDomainAppVirtualPath.Length > 1) ? HttpRuntime.AppDomainAppVirtualPath : String.Empty;

I do not know how create mocks for static class and property like HttpRuntime.AppDomainAppVirtualPath. The context, request and response have been mocked well with sample code I get from moq. I will appreciate if somebody can help me on this.

Thanks in advance.

+6  A: 

Moq can't fake static members.

As a solution you can create a wrapper class holding the static property and fake its members.
For example:

public class HttpRuntimeWrapper
{
     public virtual string AppDomainAppVirtualPath 
     { 
            get
            { 
                   return HttpRuntime.AppDomainAppVirtualPath; 
            }
     }
}

In the production code you can access this class instead of HttpRuntime and fake this property:

[Test]
public void AppDomainAppVirtualPathTest()
{
    var mock = new Moq.Mock<HttpRuntimeWrapper>();
    mock.Setup(fake => fake.AppDomainAppVirtualPath).Returns("FakedPath");

    Assert.AreEqual("FakedPath", mock.Object.AppDomainAppVirtualPath);
}

Another solution is to use Isolation framework (as Typemock Isolator) in which you can fake static classes and members.
For example:

Isolate.WhenCalled(() => HttpRuntime.AppDomainAppVirtualPath)
       .WillReturn("FakedPath");

Disclaimer - I work at Typemock

Elisha
When asking about Moq, suggesting a comerical product is a bit off.
Finglas
Why? It's an option. Wrapping static is better, but knowing your options is always a good thing.
Krzysztof Koźmic
He's asking for a solution on how to do this with Moq. That's why.
Finglas
No it doesn’t seem to be replaced HttpRuntime.AppDomainAppVirtualPath. The test crashes at this call. Any inputs?
jyothish george
Yeah, stick with Moq ;)
Finglas
MSR's Moles offers functuionaly in this space too.
Ruben Bartelink
@jyothish george, have you replaced the call in the production code to the new wrapper? In the production code instead of static call on HttpRuntime.AppDomainAppVirtualPath you should have an instance call on httpRuntimeWrapper.AppDomainAppVirtualPath
Elisha
I changed the static call to HttpRuntimeWrapper wrapper = new HttpRuntimeWrapper(); this.applicationPath = (wrapper.AppDomainAppVirtualPath.Length > 1) ? wrapper.AppDomainAppVirtualPath : String.Empty; My test fixture constructor as follows public UnitTestAspNet() { httpResponse = new Mock<HttpResponseBase>(); _httpHttpRuntimeWrapper = new Mock<HttpRuntimeWrapper>() _httpHttpRuntimeWrapper.Setup(fake => fake.AppDomainAppVirtualPath).Returns("FakedPath"); } But wrapper.AppDomainAppVirtualPath is null while running the test; any idea
jyothish george
@jyothish george, it should work, I updated the test example, checked it here and it seems to work correctly. Are you passing the mock to your class as an argument?
Elisha
@ Elisha, I am fairly new to this, sorry if I ask you such a dump question. My understanding is that, when I setup mock.Setup(fake => fake.AppDomainAppVirtualPath).Returns("FakedPath") and this would replace production code with assigned value. This just to test a custom httpmodule and start the init method via testfixture which take a mock application instance as the argument.
jyothish george
Side note, I modified the production code with wrapper object
jyothish george
When I use TypeMock Isolator, the statement Isolate.WhenCalled(() => HttpRuntime.AppDomainAppVirtualPath).WillReturn("FakedPath") would automatically replace all the instances of HttpRuntime.AppDomainAppVirtualPath in the production code? In my case, the custom httpmodule use a helper class, and the constructor of this helper class needs application path to be set
jyothish george
Isolator will automatically replace all the instances of HttpRuntime.AppDomainAppVirtualPath in the production code. Isolator won't force you to change the production code to gain testability in this case.
Elisha
+2  A: 

You cannot Moq static methods with Moq.

This is not a bad thing in reality, static methods and classes do have their place but for logic they make unit testing difficult. Naturally you'll run into them when using other libraries. To get around this you'll need to write an adapter (wrapper) around the static code, and provide an interface. For example:

class StaticClass
{
   public static int ReturnOne() 
   {
       return 1;
   }
}


interface IStatic
{
    int ReturnOne();
}

Note, I've ommited the concrete class that uses IStatic for the production code. All it would be is a class which uses IStatic and your production code would make use of this class, rather than StaticClass above.

Then with Moq:

var staticMock = new Mock<IStatic>();
staticMock.Setup(s => s.ReturnOne()).Returns(2);
Finglas
+1  A: 

As mentioned in previous answers, you can't use MoQ on static methods, and if you need to, your best shot is to create a wrapper around the static class.

However, something I've discovered recently is the Moles project. From the homepage; "Moles allows to replace any .NET method with a delegate. Moles supports static or non-virtual methods." It might be useful for your current situation.

Kirschstein
Interesting, will check it out.
Finglas