欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页  >  IT编程

测试 ASP.NET Core API Controller

程序员文章站 2022-04-04 21:28:49
测试 ASP.NET Core API Controller ......

本文需要您了解ASP.NET Core MVC/Web API, xUnit以及Moq相关知识.

这里有xUnit和Moq的介绍: 

 

Controllers可以说是ASP.NET Core MVC/Web API项目的核心, 它们把整个应用都整合到了一起. 可以说Controllers是非常重要的, 所以我们应该对它们做一些测试.

由于我几乎只做API, 所以本文不包括关于MVC功能的测试, 只包括Controller的API相关功能.

 

测试一个简单的Controller

先举一个简单点的例子:

测试 ASP.NET Core API Controller

这个Controller相对简单, 它有一个依赖项.

它一个方法, 返回类型是IActionResult, 又具体分为两种情况.

测试返回结果的类型

测试 ASP.NET Core API Controller

首先需要new出来一个被测试的RootController, 标准的叫法叫System Under Test(被测试系统). 它需要一个urlHelper作为依赖项, 那就Mock一个即可.

每组测试数据都会走一遍构造函数的.

该测试方法使用的是Theory, 用了4组数据. 执行方法后返回的结果类型应该实现了IActionResult接口, 这里可以用Assert.IsAssignableFrom<TExpected>(actual)来判断.

注: 为了方便, 我使用了resharper.

测试之前一定要重新Build一下.

然后再点击resharper在方法旁边提供的测试按钮即可:

测试 ASP.NET Core API Controller

从图可以看出resharper提供了方便快捷的图标, 在这你可以选择运行或者调试测试.

 

测试会通过的, Theory下属的4组数据将被视为4个单独的测试:

测试 ASP.NET Core API Controller

 

针对该方法的其它测试

我又添加了两个测试方法, 来测试该方法的不同路径及返回结果:

 测试 ASP.NET Core API Controller

通常一个测试方法里应该只有一个Assert. 但是第二方法里面有两个Assert, 这是因为这两个Assert都是测试的同一个行为, 所以我认为这样应该是可以的.

 

Rebuild, 测试:

测试 ASP.NET Core API Controller

也是OK的.

 

看起来针对RootController的GetRoot()方法, 我们好像已经测试了所有可执行的路径. 让我们使用测试代码覆盖率这个功能来确定一下.

点击resharper在测试类旁边提供的CoverAll按钮:

测试 ASP.NET Core API Controller

随后会出现单元测试窗口和覆盖率窗口.

 

直接看覆盖率窗口:

测试 ASP.NET Core API Controller

可以看到该Controller和方法的覆盖率都是100%了.

 

来到被测试的RootController里:

测试 ASP.NET Core API Controller

Resharper(实际上是dotCover) 在代码的左边显示出了该行代码是否已经被测试覆盖, 如果都是绿色的就说明都被覆盖了.

 

导出覆盖率结果

Resharper的代码覆盖率结果可以导出多种格式:

测试 ASP.NET Core API Controller

 

例如导出HTML后也可以查看覆盖率明细:

测试 ASP.NET Core API Controller

 

测试复杂一点的Controller

 测试 ASP.NET Core API Controller

这个ProductController略微复杂一点, 首先它需要很多依赖项.

 

看它的POST Action方法, 很多地方需要被测试:

测试 ASP.NET Core API Controller

 

测试ModelState

首先可以测试product为null的情况, 但是这个太简单了, 我就不啰嗦了.

那就测试ModelState.Invalid情况吧:

测试 ASP.NET Core API Controller

为了让ModelState Invalid, 我手动添加了ModelState的error. 和被测试方法其它必要的参数.

该方法有三个Assert, 首先判定结果类型是否为UnprocessableEntityObjectResult(422状态码), 然后再判定返回结果包含了ModelState的error.

该测试会pass, 并会覆盖这部分相关的代码:

测试 ASP.NET Core API Controller

 

测试特定方法会被调用

这里需要使用moq了, 为了让被测试方法顺利跑完, 我设定Mock版的UnitOfWork的SaveAsync()方法会返回true, (注意这个方法的返回类型是Task<bool>):

测试 ASP.NET Core API Controller

然后通过moq的Verify()方法判定repository的AddProduct()和unitOfWork的SaveAsync()方法分别被调用了.

 

Build, 测试会pass, 覆盖率目前比较大了(但是覆盖率100%并不能说明代码没问题):

测试 ASP.NET Core API Controller

 

模拟SaveAsync()后的实体数据

该项目使用的是EFCore, 在_unitOfWorkSaveAsync()之后, 变量productModel的Id就会有非0值了, 也就是说productModel在_unitOfWorkSaveAsync()方法执行之后发生了变化.

针对这种情况, 我们可以使用moq的Callback()功能:

测试 ASP.NET Core API Controller

刚开始为autoMapper的两次map动作设定了返回值.

然后在UnitOfWork的SaveAsync()执行后有个Callback()回调, 回调时相当于模拟了EFCore的保存, 把最新的值赋给了productModel(看被测试代码), (其实这里不用Callback也行....).

随后就是一系列的Assert, 判定某些方法是否执行, 返回类型是否正确, 返回的数据是否正确等.

 

Build 测试会通过的:

测试 ASP.NET Core API Controller

 

其它路径的测试

目前该方法还有两处地方没有被覆盖:

测试 ASP.NET Core API Controller

 

可以再写两个测试来覆盖它们:

测试 ASP.NET Core API Controller

这两个很简单, 不多介绍了, 注意这里使用了async版本的Assert.Throws().

 

这两个测试会pass, 最终该方法的代码覆盖率就达到100%了:

测试 ASP.NET Core API Controller

 

ASP.NET Core Web API Controller的测试就介绍这些吧.

上一篇: 和姐姐坐公交

下一篇: 私房钱