测试 ASP.NET Core API Controller

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

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

 

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

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

 

测试一个简单的Controller

先举一个简单点的例子:

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

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

测试返回结果的类型

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

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

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

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

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

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

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

 

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

 

针对该方法的其它测试

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

 

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

 

Rebuild, 测试:

也是OK的.

 

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

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

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

 

直接看覆盖率窗口:

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

 

来到被测试的RootController里:

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

 

导出覆盖率结果

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

 

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

 

测试复杂一点的Controller

 

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

 

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

 

测试ModelState

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

那就测试ModelState.Invalid情况吧:

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

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

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

 

测试特定方法会被调用

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

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

 

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

 

模拟SaveAsync()后的实体数据

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

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

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

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

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

 

Build 测试会通过的:

 

其它路径的测试

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

 

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

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

 

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

 

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