乘风原创程序

  • xUnit 编写 ASP.NET Core 单元测试的方法
  • 2020/6/9 16:09:17
  • 还记得 .NET Framework 的 ASP.NET WebForm 吗?那个年代如果要在 Web 层做单元测试简直就是灾难啊。.NET Core 吸取教训,在设计上考虑到了可测试性,就连 ASP.NET Core 这种 Web 或 API 应用要做单元测试也是很方便的。其中面向接口和依赖注入在这方面起到了非常重要的作用。

    本文就来手把手教你如何用 xUnit 对 ASP.NET Core 应用做单元测试。.NET Core 常用的测试工具还有 NUnit 和 MSTest,我本人习惯用 xUnit 作为测试工具,所以本文用的是 xUnit。

    创建示例项目

    先用 ASP.NET Core API 模板建一个应用。

    模板为我们自动创建了一个 ValuesController,为了方便演示,我们只留其中一个 Get 方法:

    public class ValuesController : ControllerBase
    {
     // GET api/values/5
     [HttpGet("")]
     public ActionResult<string> Get(int id)
     {
      return "value";
     }
    }

    然后再添加一个 xUnit 单元测试项目:

    模板自动为我们添加好了 xUnit 引用:

    <ItemGroup>
     <PackageReference Include="Microsoft.NET.Test.Sdk" Version="15.9.0" />
     <PackageReference Include="xunit" Version="2.4.0" />
     <PackageReference Include="xunit.runner.visualstudio" Version="2.4.0" />
    </ItemGroup>

    但要测试 ASP.NET Core 应用还需要添加两个 NuGet 包:

    Install-Package Microsoft.AspNetCore.App

    Install-Package Microsoft.AspNetCore.TestHost

    当然还要引入目标项目。最后的引用是这样的:

    <ItemGroup>
     <PackageReference Include="Microsoft.AspNetCore.App" Version="2.1.5" />
     <PackageReference Include="Microsoft.AspNetCore.TestHost" Version="2.1.1" />
     <PackageReference Include="Microsoft.NET.Test.Sdk" Version="15.9.0" />
     <PackageReference Include="xunit" Version="2.4.0" />
     <PackageReference Include="xunit.runner.visualstudio" Version="2.4.0" />
    </ItemGroup>
    
    <ItemGroup>
     <ProjectReference Include="..\WebApplication1\WebApplication1.csproj" />
    </ItemGroup>

    添加完引用后编译一下,确认引用没有问题。

    编写单元测试

    写单元测试一般有三个步骤:Arrange,Act 和 Assert。

    Arrange 是准备阶段,这个阶段是准备工作,比如模拟数据、初始化对象等;

    Act 是行为阶段,这个阶段是用准备好的数据去调用要测试的方法;

    Assert 是断定阶段,就是把调用目标方法返回的值和预期的值进行比较,如果和预期一致说明测试通过,否则为失败。

    按照这个步骤我们来编写一个单元测试方法,以 ValuesController 中的 Get 方法作为要测试的目标。一般一个单元测试方法就是一个测试用例。

    我们在测试工程添加一个 ValuesTests 单元测试类,然后编写一个单元测试方法,代码如下:

    public class ValuesTests
    {
     public ValuesTests()
     {
      var server = new TestServer(WebHost.CreateDefaultBuilder()
       .UseStartup<Startup>());
      Client = server.CreateClient();
     }
    
     public HttpClient Client { get; }
    
     [Fact]
     public async Task GetById_ShouldBe_Ok()
     {
      // Arrange
      var id = 1;
    
      // Act
      var response = await Client.GetAsync($"/api/values/");
    
      // Assert
      Assert.Equal(HttpStatusCode.OK, response.StatusCode);
     }
    }

    这里我们通过 TestServer 拿到一个 HttpClient 对象,用它我们可以模拟 Http 请求。我们写了一个非常简单的测试用例,完整演示了单元测试的 Arrange,Act 和 Assert 三个步骤。

    建议单元测试的方法名使用“什么应该是什么”的模式。比如上面的 GetById_ShouldBe_Ok,表示调用 GetById 这个 API 返回的结果应该是 OK 的,这样一看就知道你这个测试用例是干吗的,不需要过多的注释。

    运行单元测试

    单元测试用例写好后,打开“Test Explore”(中文版 VS 看到的是中文),在测试方法上右击,选择“Run Seleted Tests”,也可以在方法代码块内鼠标右击选择“Run Tests”:

    注意看测试方法前面图标的颜色,目前是蓝色的,表示测试用例还没有运行过。

    测试用例执行结束后如果结果和预期一致就是绿色的图标:

    如果运行结果和预期不一致就会是红色图标,然后你需要修改代码直到出现绿色图标。你可以在“Test Explore”的下方看到执行消耗的时间,也可以在 Output 窗口看到执行的细节。

    以上图标颜色的变化过程是:蓝色,红色,再绿色,有可能蓝色经过一次运行就直接变成绿色,也有可能经过很多次红色才变成绿色。测试驱动开发中的 BRG(蓝红绿)术语就是这么来的。

    调试单元测试

    你可以通过添加断点的方式在单元测试中调试。方法很简单,在需要调试的方法上右键选择“Debug Seleted Tests”即可,和平时的调试是一样的。

    如果我们要查看 API 具体返回了什么,可以通过加断点调试来查看返回结果的变量字符串值,但这种方式不是最好的选择。比如对于同一个 API,我要看看 10 种参数返回的结果是什么样的,每次都通过断点调试来查看就很麻烦。

    除了添加断点来调试,还有一种打印日志的方法来快速调试,xUnit 可以很方便地做到这一点。为此我们来修改一ValuesTests:

    public ValuesTests(ITestOutputHelper outputHelper)
    {
     var server = new TestServer(WebHost.CreateDefaultBuilder()
      .UseStartup<Startup>());
     Client = server.CreateClient();
     Output = outputHelper;
    }
    
    public ITestOutputHelper Output{ get; }
    
    // ... (省略其它代码)

    这里我们在构造函数中添加了 ITestOutputHelper 参数,xUnit 会将一个实现此接口的实例注入进来。拿到这个实例后,我们就可以用它来输出日志了:

    [Fact]
    public async Task GetById_ShouldBe_Ok()
    {
     // Arrange
     var id = 1;
    
     // Act
     var response = await Client.GetAsync($"/api/values/");
    
     // Output
     var responseText = await response.Content.ReadAsStringAsync();
     Output.WriteLine(responseText);
    
     // Assert
     Assert.Equal(HttpStatusCode.OK, response.StatusCode);
    }

    运行(注意不是 Debug)此方法,运行结束后,在“Test Explore”的下方可以可以看到“Output”字样,点击它就可以看到输出的结果,如图:

    通过这种方式,每次运行测试我们就可以很方便的查看输出结果了。

    其它

    上面我们是通过模拟 Http 请求的方式来调用 API 测试的,还有一种就是 new 一个 Controller 来直接调用它的 Action 方法来测试。比如这样:

    // Arrange
    var id = 1;
    var controller = new ValuesController();
    // Act
    var result = controller.Get(id);

    如果 Controller 没有其它依赖,这种方式当然是最方便的。但通常 Controller 是会有一个或多个依赖的,比如这样:

    public class ValuesController : Controller
    {
     private readonly ISessionRepository _sessionRepository;
    
     public ValuesController(ISessionRepository sessionRepository)
     {
      _sessionRepository = sessionRepository;
     }
    
     // ...
    }

    我们就要模拟实例化这个 Controller 的所有依赖,当然手动模拟是不现实的,因为一个依赖类还可能会依赖其它的类或接口,依赖链可能很长,你不可能每个依赖都手动去实例化它们。有一个叫 Moq 的工具可以自动来模拟实例化依赖,它的用法是这样的:

    // ..
    // Arrange
    var mockRepo = new Mock<ISessionRepository>();
    mockRepo.Setup(...);
    var controller = new HomeController(mockRepo.Object);
    
    // Act
    var result = await controller.Index();

    这种方式我是不推荐的,因为抛开 Moq 的学习成本不说,重要的是它不如模拟 Http 请求那样接近真实的调用场景,所以本文对它不作过多的介绍,大家知道有这么回事就行。