前言

當我們為Web API編寫測試用例時，代碼基本是這樣的：

public?class?UnitTest1 {private?readonly?TestServer?_server;private?readonly?HttpClient?_client;public?UnitTest1(){//?Arrange_server?=?new?TestServer(new?WebHostBuilder().UseStartup<Startup>());_client?=?_server.CreateClient();}[Fact]public?async?Task?Test1(){//?Actvar?response?=?await?_client.GetAsync("/WeatherForecast");response.EnsureSuccessStatusCode();var?responseString?=?await?response.Content.ReadAsStringAsync();var?actual?=?Newtonsoft.Json.JsonConvert.DeserializeObject<IEnumerable<WeatherForecast>>(responseString);//?AssertAssert.Equal(5,?actual.Count());} }

我們需要獲得HttpResponseMessage response，檢查它的StatusCode，如果要對響應內容進行斷言，還需要對其反序列化。

這樣的問題是，測試用例中的大量代碼都是和測試本身無關的，而且用例一多，還會形成大量重復性的代碼。

這時，可以試試FluentAssertions.Web，它為HttpResponseMessage提供了大量擴展方法，用于單元測試中的斷言。

Demo

1.斷言

將上面的測試用例改用FluentAssertions.Web，代碼如下：

[Fact] public?async?Task?Test1() {//?Actvar?response?=?await?_client.GetAsync("/WeatherForecast");//?Assertresponse.Should().Be200Ok().And.Satisfy<IEnumerable<WeatherForecast>>(model?=>{model.Should().HaveCount(5);}); }

現在，斷言是不是看起來更自然流暢！

2.失敗原因

我們修改代碼，僅返回1條數據，使得測試失敗：

可以看到，失敗原因返回了詳細的診斷信息，我們無需再像以前那樣，還需要調試代碼，檢測錯誤原因了。

結論

使用FluentAssertions.Web，不僅可以編寫干凈流暢的Web API測試，還可以從斷言的失敗原因中提取足夠的信息，從而減少調試時間。

總結

以上是生活随笔為你收集整理的如何编写干净流畅的Web API测试的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。