Mocking HttpContext.server.MapPath in ASP.NET unit testing

Question

I have working in unit testing in ASP.Net web application, now I have accessing my constructor in the model file to test which has Server.MapPath code for uploading my XMLfile,

Answer 1

How already answered, you should decouple your system

public class NugetPlatformModel
  {
    public bool IsHavingLicense { get; set; }
    public List<PlatformProducts> PlatformProduct = new List<PlatformProducts>();
    public NugetPlatformModel(IPlatformProductProvider provider)
    {
      var xmldoc = new XmlDocument();
      //System.Web.HttpContext.Current.Server.MapPath(@"~\Content\PlatformProducts.xml")
      xmldoc.Load(provider.Filepath);
    }

    public interface IPlatformProductProvider
    {
      string Filepath { get; }
    }

    public class PlatformProductProvider: IPlatformProductProvider
    {
      string _filepath;
      public string Filepath
      {
        get { return _filepath; }
        set { _filepath = value;}
      }

      public PlatformProductProvider(string path)
      {
        _filepath = path;
      }
    }

  }

And your test could be:

[Test]
    public void Account_UnlicensedCustomerIdentity_IsStudioLicenseAndIshavinglicenseFalse()
    {
      //Arrange
      // using Moq
      //var mock = new Mock<IPlatformProductProvider>();
      //IPlatformProductProvider provider = mock.Object;
      //provider.Filepath = "pippo.xml";
      // otherwise
            var provider = new PlatformProductProvider("pippo.xml");

      //Act
      NugetPlatformModel nugetPlatformModel = new NugetPlatformModel(provider);

      //Assert
      AssertEquals(false, nugetPlatformModel.IsHavingLicense);

    }

Answer 2

This is typical with code that calls static methods, it's very difficult to test while preserving separation of concern and avoiding tight coupling. Here is a generic approach to test and mock "untestable code": write a "facade wrapper" to it.

• Create a wrapper for these methods. A simple class that contains methods named sensibly, and only delegates to the untestable calls (typically static calls)

• Create an interface to that wrapper class

• Instead of directly calling the untestable methods in your client code, use the wrapper (dependency-injected using the interface provided in step 2) and call normal methods on it.

• In your unit-test, mock the wrapper with the behaviour you want.

This approach effectively reduces the coupling and separates the concerns that need to be separated. Of course, you still can't test the behaviour of the wrapper itself, but if it's simple enough (only delegating to the original calls) then it's not as big a problem.

Update:

Using shims to isolate your application from other assemblies for unit testing

Shim types are one of two technologies that the Microsoft Fakes Framework uses to let you easily isolate components under test from the environment. Shims divert calls to specific methods to code that you write as part of your test. Many methods return different results dependent on external conditions, but a shim is under the control of your test and can return consistent results at every call. This makes your tests much easier to write. Use shims to isolate your code from assemblies that are not part of your solution. To isolate components of your solution from each other, we recommend that you use stubs.

Answer 3

If you can't modify the source code, try using shims (https://msdn.microsoft.com/en-us/library/hh549176.aspx).