Asp.Net Core 单元测试正确姿势
背景
ASP.NET Core 支持依赖关系注入 (DI) 软件设计模式，并且默认注入了很多服务，具体可以参考 官方文档, 相信只要使用过依赖注入框架的同学，都会对此有不同深入的理解，在此无需赘言。
然而，在引入 IOC 框架之后，对于之前常规的对于类的依赖（new Class）变成通过构造函数对于接口的依赖（ASP.NET CORE 默认注入方式），这本身更加符合依赖倒置原则，但是对于单元测试来说确会带来另一个问题：由于层层依赖，导致在某个类的方法进行测试的时候，需要构造一大堆该类依赖的接口的实现，非常麻烦。
这个时候，我们脑子里会下意识想一个问题：为什么常用的 .Net 单元测试框架不支持依赖注入？
于是笔者带着这个问题在查阅了一些关于在单元测试中支持依赖注入的讨论Github Issue,以及其他的相关文档，突然明白一个之前一直忽视但实际却非常重要的问题：
| 在对于一个方法的单元测试中，我们应该关注的是这个方法内部的逻辑测试，而这个方法内部对于外部的依赖，则不在这个单元测试关注的范围内 |
换言之，单元测试永远都只关注需要测试的方法内部的逻辑实现，至于外部依赖方法的测试，则应该放在另一个专门针对这个方法的单元测试用例中。弄清楚这个问题，我们才能更加理解另一个单元测试不可缺少的框架——Mock框架，在我们写的测试中，应该忽略外部依赖具体的实现，而是通过模拟该接口方法来显示的指定返回值，从而降低该返回值对于当前单元测试结果的影响，而 Mock 框架（例如最常用的Moq），刚好可以满足我们对于接口的模拟需求。
相信有同学跟我有同样的疑惑，并且当我尝试在 ASP.NET CORE 单元测试中的一切外部依赖通过 Mock 的方式进行编写的时候，遇到了一些问题，才有了本篇文章，希望对有同样疑惑的同学有所帮助。
如何对 ASP.NET CORE 常用服务进行单元测试和 Mock
本文以 Xunit 以及 Moq 4.x 为例，展示在常用的 ASP.NET CORE 中会遇到的各种测试情况。
业务服务类示例如下：
public class UserService : IUserService
{
private ILogger _logger;
private IOptions _options;
private IConfiguration _configuration;
public UserService(ILogger logger, IConfiguration configuration, IOptions options )
{
this._logger = logger;
this._options = options;
this._configuration = configuration;
}
public void Login()
{
var hostName = this._configuration["RabbitMqOptions:Host"];
var options = this._options.Value;
this._logger.Log(LogLevel.Information, new EventId(), "Login", null, (m, e) => m);
}
public string GetUserInfo()
{
return $"hello world!";
}
}
public class RabbitMqOptions
{
public string Host { get; set; }
public string UserName { get; set; }
public string Password { get; set; }
} 1. IConfiguration 获取配置Mock
获取单个配置：
var mockConfiguration = new Mock();
mockConfiguration.SetupGet(_ => _["RabbitMqOptions:Host"]).Returns("127.0.0.1"); Mock IOptions
var mockRabbitmqOptions = new Mock>();
mockRabbitmqOptions.Setup(_ => _.Value).Returns(new RabbitMqOptions
{
Host = "127.0.0.1",
UserName = "root",
Password = "123456"
}); 2. Mock 方法返回参数
[Fact]
public void mock_return_test()
{
var mockInfo = "mock hello world";
var mockUserService = new Mock();
mockUserService.Setup(_ => _.GetUserInfo()).Returns(mockInfo);
var userInfo= mockUserService.Object.GetUserInfo();
Assert.Equal(mockInfo, userInfo);
} 3. ILogger 日志组件 Mock
通过 logger.Verify 验证日志至少输出一次：
[Fact]
public void log_in_login_test()
{
var logger = new Mock>();
var userService = new UserService(logger.Object);
userService.Login();
logger.Verify(_ => _.Log(It.IsAny(),
It.IsAny(),
It.IsAny<string>(),
It.IsAny(),
It.IsAnystring, Exception, string>>()),
Times.Once);
} 4. ServiceCollection 单元测试
public static void AddUserService(this IServiceCollection services, IConfiguration configuration)
{
services.TryAddSingleton();
} [Fact]
public void add_user_service_test()
{
var mockConfiguration = new Mock();
var serviceConllection = new ServiceCollection();
serviceConllection.AddUserService(mockConfiguration.Object);
var provider = serviceConllection.BuildServiceProvider();
var userService = provider.GetRequiredService();
Assert.NotNull(userService);
} 5. Middleware 单元测试
Middleware单元测试重点在于对委托 _next 的模拟
示例 HealthMiddleware:
public class HealthMiddleware
{
private readonly RequestDelegate _next;
private readonly ILogger _logger;
private readonly string _healthPath = "/health";
public HealthMiddleware(RequestDelegate next, ILogger logger, IConfiguration configuration )
{
this._next = next;
this._logger = logger;
var healthPath = configuration["Consul:HealthPath"];
if (!string.IsNullOrEmpty(healthPath))
{
this._healthPath = healthPath;
}
}
public async Task Invoke(HttpContext httpContext)
{
if (httpContext.Request.Path == this._healthPath)
{
httpContext.Response.StatusCode = (int)HttpStatusCode.OK;
await httpContext.Response.WriteAsync("I'm OK!");
}
else
await _next(httpContext);
}
}单元测试：
public class HealthMiddlewareTest
{
private readonly Mock> _mockLogger;
private readonly Mock _mockConfiguration;
private readonly string _healthPath = "/health";
private readonly HttpContext _httpContext;
private readonly Mock _mockNext;
public HealthMiddlewareTest()
{
this._mockConfiguration = new Mock();
this._mockConfiguration.SetupGet(c => c["Consul:HealthPath"]).Returns(_healthPath);
this._mockLogger = new Mock>();
this._mockLogger.Setup(_ => _.Log<object>(It.IsAny(), It.IsAny(),
It.IsAny<object>(), It.IsAny(), It.IsAnyobject, Exception, string>>()))
.Callbackobject, Exception, Func<object, Exception, string>>(
(logLevel, eventId, message, ex, fun) =>
{
Console.WriteLine($"{logLevel}\n{eventId}\n{message}\n{message}");
});
this._httpContext = new DefaultHttpContext();
this._httpContext.Response.Body = new MemoryStream();
this._httpContext.Request.Path = this._healthPath;
this._mockNext = new Mock();
this._mockNext.Setup(_ => _(It.IsAny())).Returns(async () =>
{
await this._httpContext.Response.WriteAsync("Hello World!");
});
}
[Fact]
public async Task health_request_test()
{
var middleWare = new HealthMiddleware(this._mockNext.Object, this._mockLogger.Object,
this._mockConfiguration.Object);
await middleWare.Invoke(this._httpContext);
this._httpContext.Response.Body.Seek(0, SeekOrigin.Begin);
var reader = new StreamReader(this._httpContext.Response.Body);
var returnStrs = await reader.ReadToEndAsync();
Assert.Equal("I'm OK!", returnStrs);
}
[Fact]
public async Task general_request_test()
{
this._mockConfiguration.SetupGet(c => c["Consul:HealthPath"]).Returns("/api/values");
var middleWare = new HealthMiddleware(this._mockNext.Object, this._mockLogger.Object,
this._mockConfiguration.Object);
await middleWare.Invoke(this._httpContext);
this._httpContext.Response.Body.Seek(0, SeekOrigin.Begin);
var reader = new StreamReader(this._httpContext.Response.Body);
var returnStrs = await reader.ReadToEndAsync();
Assert.Equal("Hello World!", returnStrs);
}
} 6. Mock HttpClient
HttpClient 中的 GetAsync、PostAsync 等方法底层实际都是通过HttpMessageHandler 调用 SendAsync 完成（见源码），所以在 Mock HttpClient 时，实际需要 Mock 的是 HttpMessageHandler 的 SendAsync 方法：
[Fact]
public async Task get_async_test()
{
var responseContent = "Hello world!";
var mockHttpClient = this.BuildMockHttpClient("https://github.com/", responseContent);
var response = await mockHttpClient.GetStringAsync("/api/values");
Assert.Equal(responseContent, response);
}
private HttpClient BuildMockHttpClient(string baseUrl, string responseStr)
{
var mockHttpMessageHandler = new Mock();
mockHttpMessageHandler.Protected()
.Setup>("SendAsync",
ItExpr.IsAny(),
ItExpr.IsAny()).ReturnsAsync((HttpRequestMessage request, CancellationToken token) =>
{
HttpResponseMessage response = new HttpResponseMessage();
response.Content = new StringContent(responseStr, Encoding.UTF8);
return response;
});
var mockHttpClient = new HttpClient(mockHttpMessageHandler.Object);
mockHttpClient.BaseAddress = new Uri(baseUrl);
return mockHttpClient;
} 结语
几个问题：
CI/CD 流程中应该包含单元测试
例如在编写 Repository 层进行单元测试时，经常有同学会编写依赖于数据库数据的单元测试，这样并不利于随时随地的进行单元测试检查，如果将该流程放在CI/CD中，在代码的发布过程中通过单元测试可以检查代码逻辑的正确性，同时依赖于数据库的单元测试将不会通过（通常情况下，生产环境和开发环境隔离），变相迫使开发小伙伴通过 mock 方式模拟数据库返回结果。这个原则同样适用于不能依赖三方API编写单元测试。
单元测试覆盖率
通常很多开发 Leader 都会要求开发团队编写单元测试，但是很少检查单元测试的质量，即单元测试最重要的指标——单元测试代码覆盖率，如果不注重覆盖率的提升，那么很有可能会导致开发成员为了单元测试而写单元测试，预期就会与实际情况相差甚远。保证单元测试代码覆盖率，将会大大降低代码变更带来的 Bug 率，从而节省整体开发成本。
新人问题：为何要写单元测试？
对于初次开始编写单元测试的开发人员，脑中经常会对此表示怀疑：我为什么要去验证一堆我自己写的正确的逻辑？实际这个问题包含了区分一个一般开发人员和优秀开发人员很重要的一个条件：他是否会反向思考当前逻辑的正确性。有了这种思维，看待问题才会从多个角度入手分析，对问题的本质掌握更加全面。不要怀疑，坚持写单元测试，因为这本身也是对反向思维的一种锻炼，以笔者的经验，只有当编写过一段时间之后，才会真正认识单元测试的魅力，并且开始非常习惯的在写一段逻辑之后，顺手写了对于它的单元测试。即使笔者也算很早就开始写单元测试了，但直到写这篇文章，仍然不断在加深对单元测试的认识。
其实编程也如人生三境：看山是山；看山不是山；看山还是山；阶段不同，认知不同，唯有坚持不懈，持之以恒，才能不断进步，提升境界，这不就是人追求的根本么！