空间管理您的位置: 51Testing软件测试网 » 学掌门Atstudy网校 » 日志

使用 xUnit 编写 ASP.NET Core 单元测试

上一篇 / 下一篇 2019-01-25 10:09:02 / 个人分类：软件测试

还记得 .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("{id}")]

　　public ActionResult<string> Get(int id)

　　{

　　return "value";

　　}

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

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

　　</ItemGroup>

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

Install-Package Microsoft.AspNetCore.App

　　Install-Package Microsoft.AspNetCore.TestHost

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

　　</ItemGroup>

　　</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/{id}");

　　// 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/{id}");

　　// 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 请求那样接近真实的调用场景，所以本文对它不作过多的介绍，大家知道有这么回事就行。

上文内容不用于商业目的，如涉及知识产权问题，请权利人联系博为峰小编(021-64471599-8052)，我们将立即处理。

了解更多课程内容及课程安排，可咨询QQ 2852509883 或致电客服 400-821-0951（工作日9:00-17:30）

收藏举报

TAG:

查看全部评论