ASP.NET Core Web API 集成测试

本文需要您了解ASP.NET Core Web API 和 xUnit的相关知识.

这里有xUnit的介绍: https://www.cnblogs.com/cgzl/p/9178672.html#test

ASP.NET Core集成测试官方文档: https://docs.microsoft.com/en-us/aspnet/core/test/integration-tests?view=aspnetcore-2.1

集成测试 vs 单元测试

测试金字塔, 但它只是一个指导性的概念.

 

如果所单元测试是对一个组件进行隔离测试的话, 那么集成测试则是测试多个组件共同协作产生出期待的结果.

单元测试通常很快. 而集成测试则慢的多, 因为它需要很多配置, 并且可能依赖于外部的组件, 例如数据库, 网络, 文件等.

通常在一个项目里单元测试要比集成测试多很多.

单元测试通常依赖于mock的组件, 而集成测试则使用可运行的组件.

注意: 如果一个行为可以通过单元测试或集成测试来测试的话, 那么应该使用单元测试.

 

如何进行集成测试

如果我想测试一个API Controller的Action, 我可能需要把这个项目运行起来, 等它跑起来, 发送请求并检验结果. 但这样做的话需要很多的配置工作, 并且很麻烦.

 

幸好ASP.NET Core 提供了一个Microsoft.AspNetCore.TestHost 库, 使用它就无需单独去运行被测试系统了.

ASP.NET Core应用里, 我们在Program.cs里创建WebHostBuilder, 并配置Kestrel Web服务器, 使用Startup类进行应用配置, 注册服务和中间件等. 最终在WebHostBuilder上使用Build()来创建WebHost的实例, 它可以用来在特定的URL和端口上运行并监听请求.

而这个TestHost库也使用了WebHostBuilder, 但它会自己把构建和运行web宿主的工作处理好, 也就是创建出了一个TestServer. TestServer不会在网络上进行监听, TestServer创建了一个名为Host的属性, 它的类型是IWebHost, 它可以用来处理内存里的请求对象. TestServer还会暴露一个HttpClient, 你可以用它来发送请求到被测试系统. 整个交互的过程都是在内存里完成的.

下图是被测试系统在生产环境和集成测试使用TestServer情形下的对比图:

图中:

当应用/被测试系统在生产环境运行的时候, 它使用Kestrel服务器, 监听HTTP请求, 并把它转化为HttpContext, 然后再传进ASP.NET Core的管道里.

TestServer不监听网络请求, 它使用HttpClient在内存里发送请求.

 

仔细看一下集成测试时使用TestServer的流图:

图中可以看到: 测试代码创建TestServer, TestServer创建HttpClient. 测试代码使用HttpClient发送请求接收响应. TestServer会转化请求并交给ASP.NET Core MVC/API 应用来处理.

 

一个例子

首先需要为你的应用建立集成测试项目:

 

然后需要为项目添加Microsoft.AspNetCore.TestHost 这个库:

 

被测试的是这个Controller的GetRoot()所对应的行为, 而不只是这个方法:

 

测试返回NoContent:

这里面按照之前讲的顺序, 创建IWebHostBuilder, 并用它创建TestServer, 然后TestServer创建HttpClient. 随后就使用httpClient发送请求, 返回结果, Assert即可.

需要注意的是, 在创建IWebHostBuilder的时候, 我使用了被测试系统的Startup类来进行配置, 并设定的环境是Development.

 

由于我这个项目可以看作是真实项目, 所以第一次运行该测试的时候, 测试是Fail的. 因为Startup里面有很多配置并不满足测试要求.

在我把IpRateLimiting, HttpsRedirection, Authentication, AuthorizeFilter等中间件/组件去掉之后, 测试才通过:

 

所以这就引出了一个问题, Startup里面的配置在开发时 和 测试时 以及 生产运行时 可能是不太一样的.

我的Startup里面已经有很多代码了, 如果再进行环境判断, 那就会更乱了.

所以我决定为集成测试新建立一个Startup配置类:

 

ASP.NET Core项目也支持多环境的多个Startup配置类, 这部分内容请参考官方文档: https://docs.microsoft.com/en-us/aspnet/core/fundamentals/environments?view=aspnetcore-2.1#environment-based-startup-class-and-methods.

 

然后修改代码, 使用这个测试专用的Startup即可:

测试会通过.

 

被测试系统有依赖项

下面继续测试GetRoot方法的另一个路径, 这个路径会用到RootController的依赖项IUrlHelper. 

在集成测试里, 通常情况下是不使用Mocking技术的. 所以在这里我也不会mock IUrlHelper:

这里没有mock任何东西. 此外这个被测试的行为需要设置AcceptHeader.

测试会Pass的, TestServer帮我搞定了一切:

 

优化测试配置

写了两个测试方法, 又引出了一个新的问题: 这两个方法有一些共同的设置代码, 这些设置可能会比较耗资源. 我们可以把这些设置放在构造函数里面, 但是如果使用Theory并含有多个InlineData的话, 就会多次运行构造函数里的设置代码, 可能会非常好资源(时间).

所以我们应该考虑使用test fixture 这里有介绍: http://www.cnblogs.com/cgzl/p/8438019.html#share

而且我们可以使用WebApplicationFactory来构建TestServer, 使用WebApplicationFactory的好处是可以灵活的进行自定义配置. 

要使用WebApplicationFactory, 需要添加库: Microsoft.AspNetCore.Mvc.Testing

 

使用该库之后, 代码应该如下:

但是却有一个问题, 这里我选择的时StartupIntegrationTest. 而电脑环境变量设置的是Development, 而调试测试之后发现走的是StartupDevelopment.

 

也许这是个Bug? 或者就是这样的意图. 那我暂时还是使用原始的方法创建TestServer吧, 下面是我使用的代码:

建立一个TestServerFixture, 需要使用IDisposable来做清理工作:

 

而测试类注入该Fixture即可:

 

然后重跑测试, 会pass的:

 

一个复杂点的例子

我要测试这个Controller下CreateProduct方法对应的行为. 该Controller需要很多依赖项, 其中两个还需要使用数据库.

 

通常情况下集成测试里使用的数据库和生产环境中使用的数据库不同, 在测试环境我更倾向于使用内存类数据库.

EF Core里面至少有两个内存类的数据库提供商:

• Microsoft.EntityFrameworkCore.InMemory, 这个都应该知道.
• Microsoft.EntityFrameworkCore.Sqlite. 虽然说Sqlite通常是把数据保存到文件, 但是提供商为它提供了一个内存模式, 把数据库保存到了内存里.

在StartupIntegrationTest里, 我就使用InMemory吧;

 

 

 下面是测试方法的代码:

这代码其实很简单, 就是对应着被测试的Controller方法做一些需要的设定即可, 例如Headers, Content-Type等等.

需要注意的是Content-Type是在Content的Header里设置, 而不是Request的Headers里设置, 否则会报乱用Header的错.

该测试会pass:

 

最后针对该行为再做一个Model验证失败的测试:

没什么不同, 就是model的Name属性超长了.

这个测试同样会通过:

 

集成测试就简单介绍这些.......