ASP.NET Core 支持依賴關係注入 (DI) 軟件設計模式,而且默認注入了不少服務,具體能夠參考 官方文檔, 相信只要使用過依賴注入框架的同窗,都會對此有不一樣深刻的理解,在此無需贅言。git
然而,在引入 IOC 框架以後,對於以前常規的對於類的依賴(new Class)變成經過構造函數對於接口的依賴(ASP.NET CORE 默認注入方式),這自己更加符合依賴倒置原則,可是對於單元測試來講確會帶來另外一個問題:因爲層層依賴,致使在某個類的方法進行測試的時候,須要構造一大堆該類依賴的接口的實現,很是麻煩。github
這個時候,咱們腦子裏會下意識想一個問題:爲何經常使用的 .Net 單元測試框架不支持依賴注入?
數據庫
因而筆者帶着這個問題在查閱了一些關於在單元測試中支持依賴注入的討論Github Issue,以及其餘的相關文檔,忽然明白一個以前一直忽視但實際卻很是重要的問題:編程
在對於一個方法的單元測試中,咱們應該關注的是這個方法內部的邏輯測試,而這個方法內部對於外部的依賴,則不在這個單元測試關注的範圍內 |
換言之,單元測試永遠都只關注須要測試的方法內部的邏輯實現,至於外部依賴方法的測試,則應該放在另外一個專門針對這個方法的單元測試用例中。弄清楚這個問題,咱們才能更加理解另外一個單元測試不可缺乏的框架——Mock框架,在咱們寫的測試中,應該忽略外部依賴具體的實現,而是經過模擬該接口方法來顯示的指定返回值,從而下降該返回值對於當前單元測試結果的影響,而 Mock 框架(例如最經常使用的Moq),恰好能夠知足咱們對於接口的模擬需求。設計模式
相信有同窗跟我有一樣的疑惑,而且當我嘗試在 ASP.NET CORE 單元測試中的一切外部依賴經過 Mock 的方式進行編寫的時候,遇到了一些問題,纔有了本篇文章,但願對有一樣疑惑的同窗有所幫助。api
本文以 Xunit 以及 Moq 4.x 爲例,展現在經常使用的 ASP.NET CORE 中會遇到的各類測試狀況。框架
業務服務類示例以下:asp.net
public class UserService : IUserService { private ILogger _logger; private IOptions<RabbitMqOptions> _options; private IConfiguration _configuration; public UserService(ILogger<UserService> logger, IConfiguration configuration, IOptions<RabbitMqOptions> options) { this._logger = logger; this._options = options; this._configuration = configuration; } public void Login() { var hostName = this._configuration["RabbitMqOptions:Host"]; var options = this._options.Value; //do something 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; } }
獲取單個配置:async
var mockConfiguration = new Mock<IConfiguration>(); mockConfiguration.SetupGet(_ => _["RabbitMqOptions:Host"]).Returns("127.0.0.1");
Mock IOptions<T>ide
var mockRabbitmqOptions = new Mock<IOptions<RabbitMqOptions>>(); mockRabbitmqOptions.Setup(_ => _.Value).Returns(new RabbitMqOptions { Host = "127.0.0.1", UserName = "root", Password = "123456" });
[Fact] public void mock_return_test() { var mockInfo = "mock hello world"; var mockUserService = new Mock<IUserService>(); mockUserService.Setup(_ => _.GetUserInfo()).Returns(mockInfo); var userInfo= mockUserService.Object.GetUserInfo(); Assert.Equal(mockInfo, userInfo); }
經過 logger.Verify 驗證日誌至少輸出一次:
[Fact] public void log_in_login_test() { var logger = new Mock<ILogger<UserService>>(); var userService = new UserService(logger.Object); userService.Login(); logger.Verify(_ => _.Log(It.IsAny<LogLevel>(), It.IsAny<EventId>(), It.IsAny<string>(), It.IsAny<Exception>(), It.IsAny<Func<string, Exception, string>>()), Times.Once); }
public static void AddUserService(this IServiceCollection services, IConfiguration configuration) { services.TryAddSingleton<IUserService, UserService>(); }
[Fact] public void add_user_service_test() { var mockConfiguration = new Mock<IConfiguration>(); var serviceConllection = new ServiceCollection(); serviceConllection.AddUserService(mockConfiguration.Object); var provider = serviceConllection.BuildServiceProvider(); var userService = provider.GetRequiredService<IUserService>(); Assert.NotNull(userService); }
Middleware單元測試重點在於對委託 _next 的模擬
示例 HealthMiddleware:
public class HealthMiddleware { private readonly RequestDelegate _next; private readonly ILogger _logger; private readonly string _healthPath = "/health"; public HealthMiddleware(RequestDelegate next, ILogger<HealthMiddleware> 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<ILogger<HealthMiddleware>> _mockLogger; private readonly Mock<IConfiguration> _mockConfiguration; private readonly string _healthPath = "/health"; private readonly HttpContext _httpContext; private readonly Mock<RequestDelegate> _mockNext; //middleware next public HealthMiddlewareTest() { this._mockConfiguration = new Mock<IConfiguration>(); this._mockConfiguration.SetupGet(c => c["Consul:HealthPath"]).Returns(_healthPath); this._mockLogger = new Mock<ILogger<HealthMiddleware>>(); this._mockLogger.Setup(_ => _.Log<object>(It.IsAny<LogLevel>(), It.IsAny<EventId>(), It.IsAny<object>(), It.IsAny<Exception>(), It.IsAny<Func<object, Exception, string>>())) .Callback<LogLevel, EventId, object, 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<RequestDelegate>();//next 委託 Mock this._mockNext.Setup(_ => _(It.IsAny<HttpContext>())).Returns(async () => { await this._httpContext.Response.WriteAsync("Hello World!"); //模擬http請求最終輸出 }); } [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);//執行middleware this._httpContext.Response.Body.Seek(0, SeekOrigin.Begin); //獲取監控檢查請求獲取到的response內容 var reader = new StreamReader(this._httpContext.Response.Body); var returnStrs = await reader.ReadToEndAsync(); Assert.Equal("I'm OK!", returnStrs);//斷言健康檢查api是否中間件攔截輸出 "I'm OK!" } [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); //斷言非健康檢查請求api返回模擬 Hello World! } }
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<HttpMessageHandler>(); mockHttpMessageHandler.Protected() .Setup<Task<HttpResponseMessage>>("SendAsync", ItExpr.IsAny<HttpRequestMessage>(), ItExpr.IsAny<CancellationToken>()).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 率,從而節省總體開發成本。
新人問題:爲什麼要寫單元測試?
對於初次開始編寫單元測試的開發人員,腦中常常會對此表示懷疑:我爲何要去驗證一堆我本身寫的正確的邏輯?實際這個問題包含了區分一個通常開發人員和優秀開發人員很重要的一個條件:他是否會反向思考當前邏輯的正確性。有了這種思惟,看待問題纔會從多個角度入手分析,對問題的本質掌握更加全面。不要懷疑,堅持寫單元測試,由於這自己也是對反向思惟的一種鍛鍊,以筆者的經驗,只有當編寫過一段時間以後,纔會真正認識單元測試的魅力,而且開始很是習慣的在寫一段邏輯以後,順手寫了對於它的單元測試。即便筆者也算很早就開始寫單元測試了,但直到寫這篇文章,仍然不斷在加深對單元測試的認識。
其實編程也如人生三境:看山是山;看山不是山;看山仍是山;階段不一樣,認知不一樣,惟有堅持不懈,鍥而不捨,才能不斷進步,提高境界,這不就是人追求的根本麼!