CoreCRM 开发实录 —— 单元测试之 Mock UserManager 和 SignInManager
单元测试的核心就是：只测试眼前的逻辑。这就要求所有的依赖项都要使用仿类来代替，也就是所谓的 Mock Object。在测试 ProfileRepository 和 AccountController 的时候，我遇到了需要对 UserManager 和 SignInManager 进行 Mock 的需求。因为这两个组件相互依赖，还依赖别的组件，我折腾了好一阵才搞定这个问题。具体的方法分两种：直接使用 Moq 进行 Mock 和使用 InMemory Database 进行 Mock。下面分别来说明一下。
一、 使用 InMemory Database 进行 Mock
在 ProfileRepository 的测试中，我使用了 InMemory 这个方案。因为之前对单元测试的一些误解（使用 PHPUnit 而遗留下来的想法），我最直接想到的就是在数据库中添加数据，然后让各个组件去直接读数据库。当然，为了让测试能够飞速运行，我需要使用一个在内存里运行的数据库。但严格来说，这样就不算是单元测试了，而有一些集成测试的味道。只是使用内存数据库，速度上并没有那么慢，所以权且当成是一种扩展版的单元测试吧。这里有两个内存数据库可以选：一个是 SQLite 的 :memory: 模式，这个是一个接近完整的数据库，只是在外键的约束上可能还有点问题；另一个是 EF Core 的 InMenory 数据库。这个只是一个内存里保存数据的容器，其实并不是一个数据库，没有 SQLite 那样的数据一致性检查。这里，我使用的是 InMemory Database，这样可以让这个测试更“单元”一点：
public ProfileRepositoryTests()
{
var services = new ServiceCollection();
services.AddEntityFramework()
.AddEntityFrameworkInMemoryDatabase()
.AddDbContext<ApplicationDbContext>(options => {
options.UseInMemoryDatabase();
});
services.AddIdentity<ApplicationUser, IdentityRole>()
.AddEntityFrameworkStores<ApplicationDbContext>();
// Taken from https://github.com/aspnet/MusicStore/blob/dev/test/MusicStore.Test/ManageControllerTest.cs (and modified)
// IHttpContextAccessor is required for SignInManager, and UserManager
var context = new DefaultHttpContext();
context.Features.Set<IHttpAuthenticationFeature>(
new HttpAuthenticationFeature());
services.AddSingleton<IHttpContextAccessor>(h =>
new HttpContextAccessor { HttpContext = context });
var serviceProvider = services.BuildServiceProvider();
_dbContext = serviceProvider.GetRequiredService<ApplicationDbContext>();
_userManager = serviceProvider.GetRequiredService<UserManager<ApplicationUser>>();
Task.Run(async () => {
await _userManager.CreateAsync(new ApplicationUser {
UserName = "test1" }, "11aaAA_");
await _userManager.CreateAsync(new ApplicationUser {
UserName = "test2" }, "11aaAA_");
var user = await _userManager.FindByNameAsync("test2");
var profile = new Profile()
{
AccountID = user.Id,
Avatar = "avatar-file"
};
_dbContext.Add(profile);
_dbContext.SaveChanges();
user.ProfileID = profile.Id;
_dbContext.Update(user);
_dbContext.SaveChanges();
}).Wait();
}
可以看到，其实就是把 Startup 里的一些内容复制过来而已。这里 _userManager 和 _dbContext 都是做为 TestClass 的成员而存在的。可以使用 Property，也可以使用成员变量。这样做的意义主要是一些测试可能需要再增加一些数据，歌者直接去 Assert 数据库里有对应的数据。当然，如果为了更灵活的测试，这里的添加数据的问题也可以提出去，做了一个单独的函数，然后在 Arrange 阶段来调用。怎么安排测试的结构，取决于测试的复杂度和个人的风格，没有太多的标准。
二、直接使用 Moq 来 Mock
在 Mock AccountController 里的 UserManager 时，我发现了另一个解决方案，相比上面的方案，这个更加直接一些：
public static Mock<SignInManager<TUser>>
MockSignInManager<TUser>(Mock<UserManager<TUser>> manager)
where TUser : class
{
var context = new Mock<HttpContext>();
// var manager = MockUserManager<TUser>();
return new Mock<SignInManager<TUser>>(manager.Object,
new HttpContextAccessor { HttpContext = context.Object },
new Mock<IUserClaimsPrincipalFactory<TUser>>().Object,
null, null)
{ CallBase = true };
}
public static Mock<UserManager<TUser>> MockUserManager<TUser>()
where TUser : class
{
IList<IUserValidator<TUser>> UserValidators =
new List<IUserValidator<TUser>>();
IList<IPasswordValidator<TUser>> PasswordValidators =
new List<IPasswordValidator<TUser>>();
var store = new Mock<IUserStore<TUser>>();
UserValidators.Add(new UserValidator<TUser>());
PasswordValidators.Add(new PasswordValidator<TUser>());
var mgr = new Mock<UserManager<TUser>>(store.Object, null, null,
UserValidators, PasswordValidators, null, null, null, null);
return mgr;
}
使用这两个函数，就可以直接创建 UserManager 和 SignInManager 的 Mock 了。不过，在使用 SignInManager 模拟登录的时候还要注意：
_mockSignInManager.Setup(m =>
m.PasswordSignInAsync(It.IsAny<ApplicationUser>(),
It.IsAny<string>(),
It.IsAny<bool>(),
It.IsAny<bool>()))
.Returns(Task.FromResult(SignInResult.Success));
也就是说，创建“登录成功”，不能直接 new 一个 SignInResult，因为不能修改 SignInResult 的状态，而是要使用它已经写好的带状态的结果。
这两种方式各有用处。比如 InMemory Database 的方案，不但可以对 UserManager 和 SignInManager 的结果进行控制，还提供了一个可以写入和检查的数据库。而直接 Mock 的方案，则干扰更少，更专注于逻辑。我个人感觉，在对 Repository 的测试中，使用 InMemory Database 可能更合适一点，然后在其它地方，因为 Repository 隔离了数据访问，所以可以直接对 Repository 进行 Mock，这时候就可以使用直接 Mock 的方案。
三、Logger 的 Mock
在测试 AccountController 的时候，还需要对 ILogger 和 ILoggerFactory 进行 Mock，这当然也不是什么难事：
_mockLogger.Setup(m => m.Log(It.IsAny<LogLevel>(),
It.IsAny<EventId>(),
It.IsAny<FormattedLogValues>(),
It.IsAny<Exception>(),
It.IsAny<Func<object, Exception, string>>()));
_mockLoggerFactory.Setup(m =>
m.CreateLogger(It.IsAny<string>())).Returns(_mockLogger.Object);
也就是，得 Mock 两个东西。这当然是因为 Controller 里都是依赖于 ILoggerFactory ，然后再使用 factory 创建 ILogger。
四、UrlHelper 的 Mock
最后一个坑是 UrlHelper。通常一个 Controller 都会有 RedirectTo 一个 Action 或者一个 URL 的需求，那就不可避免要用到 UrlHelper。而 Controller 需要单独进行 Mock：
var mockUrlHelper = new Mock<IUrlHelper>();
mockUrlHelper.Setup(m => m.IsLocalUrl(It.IsAny<string>())).Returns(true);
controller.Url = mockUrlHelper.Object;
下面参考资料里的代码要复杂的多，应该是因为 ASP.NET Core 的版本问题造成的。我这个“简单的版本”，是针对 1.1.0 版本的。如果以后有变化，可能会在别的地方再说明吧。
完整的代码请到下面两个 repo 中的一个去看：
GitHub: http://github.com/holmescn/CoreCRM
Codint.NET: https://coding.net/u/holmescn/p/CoreCRM/git
参考链接：
直接 Mock 的代码是请看这里
使用 InMemory Database 的请看这里
UrlHelper 的原始想法来自这里
