Mocking IPrincipal in ASP.NET Core

问题:

I have an ASP.NET MVC Core application that I am writing unit tests for. One of the action methods uses User name for some functionality:

SettingsViewModel svm = _context.MySettings(User.Identity.Name);

which obviously fails in the unit test. I looked around and all suggestions are from .NET 4.5 to mock HttpContext. I am sure there is a better way to do that. I tried to inject IPrincipal, but it threw an error; and I even tried this (out of desperation, I suppose):

public IActionResult Index(IPrincipal principal = null) {
    IPrincipal user = principal ?? User;
    SettingsViewModel svm = _context.MySettings(user.Identity.Name);
    return View(svm);
}

but this threw an error as well. Couldn't find anything in the docs either...

回答1:

The controller’s User is accessed through the HttpContext of the controller. Latter is stored within the ControllerContext.

The easiest way to replace the user is by assigning a different HttpContext with a constructed user. We can use DefaultHttpContext for this purpose, that way you don’t have to mock everything:

var user = new ClaimsPrincipal(new ClaimsIdentity(new Claim[]
{
     new Claim(ClaimTypes.NameIdentifier, "1"),
     new Claim(MyCustomClaim, "example claim value")
}));

var controller = new SomeController(dependencies…);
controller.ControllerContext = new ControllerContext()
{
    HttpContext = new DefaultHttpContext() { User = user }
};

回答2:

In previous versions you could have set User directly on the controller, which made for some very easy unit tests.

If you look at he source code for ControllerBase you will notice that the User is extracted from HttpContext.

/// <summary>
/// Gets or sets the <see cref="ClaimsPrincipal"/> for user associated with the executing action.
/// </summary>
public ClaimsPrincipal User
{
    get
    {
        return HttpContext?.User;
    }
}

and the controller accesses the HttpContext via ControllerContext

/// <summary>
/// Gets the <see cref="Http.HttpContext"/> for the executing action.
/// </summary>
public HttpContext HttpContext
{
    get
    {
        return ControllerContext.HttpContext;
    }
}

You will notice that these two are read only properties. The good news is that ControllerContext property allows for setting it's value so that will be your way in.

So the target is to get at that object. In Core HttpContext is abstract so it is a lot easier to mock.

Assuming a controller like

public class MyController : Controller {
    IMyContext _context;

    public MyController(IMyContext context) {
        _context = context;
    }

    public IActionResult Index() {
        SettingsViewModel svm = _context.MySettings(User.Identity.Name);
        return View(svm);
    }

    //...other code removed for brevity 
}

Using Moq, a test could look like this

public void Given_User_Index_Should_Return_ViewResult_With_Model() {
    //Arrange 
    var username = "FakeUserName";
    var identity = new GenericIdentity(username, "");

    var mockPrincipal = new Mock<IPrincipal>();
    mockPrincipal.Setup(x => x.Identity).Returns(identity);
    mockPrincipal.Setup(x => x.IsInRole(It.IsAny<string>())).Returns(true);

    var mockHttpContext = new Mock<HttpContext>();
    mockHttpContext.Setup(m => m.User).Returns(mockPrincipal.Object);

    var model = new SettingsViewModel() {
        //...other code removed for brevity
    };

    var mockContext = new Mock<IMyContext>();
    mockContext.Setup(m => m.MySettings(username)).Returns(model);

    var controller = new MyController(mockContext.Object) {
        ControllerContext = new ControllerContext {
            HttpContext = mockHttpContext.Object
        }
    };

    //Act
    var viewResult = controller.Index() as ViewResult;

    //Assert
    Assert.IsNotNull(viewResult);
    Assert.IsNotNull(viewResult.Model);
    Assert.AreEqual(model, viewResult.Model);
}

回答3:

I would look to implement an Abstract Factory Pattern.

Create an interface for a factory specifically for providing user names.

Then provide concrete classes, one which provides User.Identity.Name, and one that provides some other hard coded value that works for your tests.

You can then use the appropriate concrete class depending on production versus test code. Perhaps looking to pass the factory in as a parameter, or switching to the correct factory based on some configuration value.

interface IUserNameFactory
{
    string BuildUserName();
}

class ProductionFactory : IUserNameFactory
{
    public BuildUserName() { return User.Identity.Name; }
}

class MockFactory : IUserNameFactory
{
    public BuildUserName() { return "James"; }
}

IUserNameFactory factory;

if(inProductionMode)
{
    factory = new ProductionFactory();
}
else
{
    factory = new MockFactory();
}

SettingsViewModel svm = _context.MySettings(factory.BuildUserName());

回答4:

There is also the possibility to use the existing classes, and mock only when needed.

var user = new Mock<ClaimsPrincipal>();
_controller.ControllerContext = new ControllerContext
{
    HttpContext = new DefaultHttpContext
    {
        User = user.Object
    }
};