如何使用ASP.NET Identity 3对ASP.NET 5帐户控制器进行单元测试

Question

I would like to unit test an ASP.NET 5 account controller using ASP.NET Identity 3 but I am not sure what is the best way to do this. My account controller is using the UserManager and as I can see this UserManager class does not have an interface that I can use to mock it, I have checked the source code. One way I thought would be be for me to wrap it into another class that implements an interface and then use that for mocking. Is this the only way to make the account controller unit testable or there other better ways.Please note I am not referring to integration tests that require database use.

Answer 1

That's what I had to do to get it to work. I completely abstracted the Identity Model behind interfaces to make it persistence ignorant.

I created some default classes that basically wrapped the Identity Model that allowed me to separate the tight coupling to Identity 3, which allowed for mocking and making my controllers unit testable.

Answer 2

Actually, there is a Typemock Isolator tool, which allows to mock not only the interfaces. You can mock and test almost anything, without creating a huge amount of wrappers, or interfaces etc.

Answer 3

There are 2 ways to go about doing this.

Mocking Framework

UserManager is not a sealed class. You can use existing frameworks like NSubstitute, Mocks, etc. to inject a dummy UserManager into your calling code. Most of these frameworks (that I am aware of) support overriding behavior on non-sealed classes in the mock as long as the method has been marked as virtual which almost all these methods on UserManager have. Here is an example of how to do it with NSubstitute (my framework of choice).

var uManager = NSubstitute.Substitute.For<UserManager<MyUserType, int>>();
var result = new ClaimsIdentity();
uManager.CreateIdentityAsync(NSubstitute.Arg.Any<MyUserType>(), "login").Returns(Task.FromResult(result));
var controller = new MyAuthController(uManager);
controller.DoSomething();

Code Refactor

This is a more involved approach but maybe better for the long run.

Here is the class signature of the UserManager ( version 2 of Identity framework but I imagine version 3 does not have any breaking changes on the class itself but it could be slightly different ).

public class UserManager<TUser, TKey> : IDisposable where TUser : class, IUser<TKey> where TKey : IEquatable<TKey>

The class, as you noted, does not implement an IUserManager interface but is not sealed so you can create your own implementation. Your implementation can implement an interface and this interface can specify existing methods on the original UserManager<TUser, TKey> class, you can then implement the interface using explicit implementation .

Example method signature and then your implementation.

Method on UserManager<TUser, TKey>

public virtual Task<ClaimsIdentity> CreateIdentityAsync(TUser user, string authenticationType)

Method on your interface (strongly typed in this example).

Task<ClaimsIdentity> CreateIdentityAsync(MyUserType user, string authenticationType);

Implementation on your concrete class (strongly typed in this example).

async Task<ClaimsIdentity> IMyUserTypeManager.CreateIdentityAsync(MyUserType user, string authenticationType)
{
    return await this.CreateIdentityAsync(user, authenticationType);
}

Creating a mock with your controller would be the same as illustrated in the first example above.

The benefit of this approach:

1. You have now better abstracted the fact that you are using the ASP.NET Identity framework from your implementing code. This should make it easier to make updates and/or changes ASP.NET Identity in the future.
2. You can now reference interfaces instead of concrete classes by the calling code. This will make it easier to unit test as you can more easily create mocks/substitutes for these interfaces.

The downside of this approach is you have to create and maintain a proxy to the Identity code but usually the number of methods that you actually use/call into is fairly limited so its not much more work.