如何测试 ASP.NET Core Web API最新消息

在本文中，我们将研究如何测试你的 ASP .NET Core 2.0 Web API 解决方案。我们将了解使用单元测试进行内部测试，使用全新的 ASP .NET Core 的整合测试框架来进行外部测试。本文要点

正确理解并使用单元测试和你的 ASP .NET Core Web API 解决方案一样重要。了解并使用模拟资料进行单元测试可以帮助你获得稳定的测试场景。为 ASP .NET Core Web API 解决方案在 .NET Core 2.1 中建立模拟资料专案。了解并设定整合测试来从外部测试 API，这样可以帮助完整测试 ASP .NET Core 2.1 Web API 解决方案。.NET Core 最初是在 2016 年释出的，随着 .NET Core 2.0 的释出，微软拥有了下一个通用、模组化、跨平台和开源的平台主版本。.NET Core 已经建立了许多 API，在当前版本的 .net 框架中均可用。它最初是为下一代 ASP .NET 解决方案而建立的，但现在成了许多其他场景的驱动和基础，包括物联网、云端计算和下一代移动解决方案。在本系列文章中，我们将探讨 .NET Core 的一些好处，以及它如何不仅能使传统的 .NET 开发人员受益，还能使所有需要为市场带来健壮、高效和经济的解决方案的技术人员受益。

在使用 ASP .NET Core 2.1 Web API 构建并开发一组丰富的 API 的时候，需要记住这只是实现稳定且高效的解决方案的第一步。为你的解决方案提供一个稳定的环境是非常重要的。获得优秀的解决方案不仅需要完整地构建 API，还需要严格地测试你的 API，保证使用者有良好的体验。

这篇文章是我之前为 InfoQ 写的《针对 ASP.NET Core Web API 的先进架构》的后续文章。请放心，你不需要阅读另外一篇文章，就可以从这篇文章了解到如何从测试中获得好处，但读一下那篇文章可以帮助你更多了解我是如何构建我讨论的解决方案的。在过去的几年里，我花了大量时间来思考在为客户构建 API 时进行测试。了解 ASP .NET Core 2.1 Web API 的架构，可以帮助拓宽你的了解。

本篇文章中的例子的解决方案和所有程式码都可以在我的GitHub 库中找到。

ASP .NET Core Web API 快速入门

让我们一起来快速了解一下 .NET 和 ASP .NET Core。ASP .NET Core 是 Microsoft 创造的全新 Web 框架，以便摆脱自 ASP .NET 1.0 以来一直存在的遗留技术。ASP .NET Core 2.1 摆脱这些遗留依赖，从头开始开发框架，因此可以给开发人员提供更高的效能，并且它是为跨平台执行而构建的。

什么是单元测试？

对有些人来说，测试你的软件可能是一个新的概念，但是它很简单。我们从单元测试开始。维基百科对于它的严格定义是“是一种软件测试方法，对源代码的独立单元、一组或多组计算机程式模组以及相关的控制资料、使用程式和操作程式都进行测试，以了解它们是否适合使用”。我比较喜欢的是一个外行的解释，单元测试是保证在你添加了新的功能或进行了缺陷修复之后，你的解决方案中的程式码能像预期一样执行。我们测试了一个简单的程式码示例，来保证它符合我们的预期。让我们来看一下单元测试示例：

复制程式码

[Fact]

public async Task AlbumGetAllAsync()

{

// Arrange

// Act

var albums = await _repo.GetAllAsync();

// Assert

Assert.Single(albums);

}

优秀的单元测试有三个部分组成。第一个是Arrange的部分，用来设定测试中可能需要的任何资源。在上面的例子中，我没有进行任何设定，所以 Arrange 的部分是空的 (但我还是为它保留了注释)。第二个部分是Act的部分，用来执行测试的部分。在我们的例子中，我呼叫数据库中的专辑实体型别，返回当前使用的库中的资料来源完整的专辑实体。单元测试的最后一个部分是Assert的部分，用来验证待测试的操作是否正确。对于该测试，我检验是否从数据库中返回了一个专辑。

在本文中，我会使用 xUnit 工具进行单元测试。xUnit 是 .NET Framework 和现在的 .NET Core 的开源包。我们需要 .NET Core 版本的 xUnit，在你安装 .NET Core 2.1 SDK 的时候就已经直接获得了。你可以通过 .NET Core cli 指令 dotnet test，或是通过你喜欢的 IDE（如 Visual Studio 2017、Visual Studio Code 或 JetBrain 的 Rider.）中的专案模板来创造新的单元测试专案。

图 1：在 Visual Studio 2017 中建立新的单元测试专案

现在，让我们深入到测试你的 ASP .NET Core Web API 解决方案的单元测试中来。

Web API 要单元测试一些什么？

我非常支援使用单元测试来为你的客户保证稳定和健壮的 API。但我清楚地知道要如何使用单元测试，知道要测试什么东西。我相信，你要恰到好处地对解决方案进行单元测试，而不要做多余的测试。这是什么意思呢？可能我的观点会引发很多评论，但是我不太注重要 100% 覆盖你的测试。我是否认为我们需要能覆盖 API 解决方案重要部分的测试，单独隔开每个区域，保证每个程式码段都是正确的？当然！我会这么做，这也是我想要讨论的。

由于我们的示例 Chinook.API 很小，并且可以通过整合测试来完成测试（本文稍后讨论），我发现在 Domain 和 Data 专案中我最关注单元测试。我不会详细讨论单元测试的方法（因为这个问题超出了本文讨论的范围）。我想要让你不依赖于生产数据库的资料，从而在 Domain 和 Data 专案中进行更多的测试。这是我们下一个要讨论的问题，模拟资料和物件。

为什么在单元测试中使用模拟资料和物件？

我们已经讨论了为什么我们要进行单元测试，单元测试一些什么内容。接下来，了解如何准确地单元测试 ASP .NET Core Web API 解决方案是非常重要的。资料是测试 API 的重点。测试可预测的资料集是非常重要的。这就是为什么我不推荐使用生产资料或者其他可能随着时间根据你的了解和认知会改变的资料。我们需要稳定的资料集来保证所有单元测试的执行，确保程式码段之间的测试是相同的。比如说，在我测试 Chinook.Domain 专案的时候，我想要得到 ID 是 42 的专辑，我需要保证它的确存在，并拥有类似专辑名称这样的细节，和一条艺术家资料有关联关系。我还希望确保在我从资料来源中得到一系列专辑时，大小满足我编写的单元测试。

许多业内人士使用“模拟资料”这一术语来表示这一类资料。有很多为单元测试产生模拟资料的方法，我希望你能创造出尽可能“真实”的资料集。你给测试创造的资料越好，测试效果也会越好。我会建议你确保资料没有隐私问题，不包含公司或客户的个人资料或敏感资料。

要满足我们对于干净、稳定资料的需求，我单独建立了一个专案，封装了单元测试专案的模拟资料。让我们称其为 Chinook.MockData（就像你能在示例中看到的一样）。我的 MockData 专案几乎和 Chinook.Data 专案相同。它们都拥有相同数量的数据库，都和相同的界面依附。我希望 MockData 专案储存在依赖注入 (DI) 容器中，这样 Chinook.Domain 专案就可以像连线到了生产资料来源那样得到使用。这就是为什么我很喜欢依赖注入。它可以帮助我通过配置切换 Data 专案，而不需要做任何程式码变更。

整合测试：什么是针对 Web API 的新测试？

在我们为 ASP .NET Core Web API 解决方案执行并验证了单元测试之后，我们要看一个完全不同型别的测试。我希望单元测试可以验证并确保对解决方案内部元件的期望。当我们对内部测试的质量满意的时候，我们需要从外部界面进行 API 测试，这就是我们所说的整合测试。

整合测试需要在所有的元件完成的时候编写并执行，所以你的 API 可以通过正确的 HTTP 响应来验证。单元测试时测试的是单独隔离开的程式码段，而整合测试时测试的是 HTTP 端点上每个 API 的整体逻辑。测试将会遵循 API 的完整工作流，从 API 专案的控制器到域专案管理器，最后到 Data 专案的库（返回来响应）。

创造整合测试专案

要使用你现有的测试知识，整合测试功能是基于现有的单元测试库的。我将使用 xUnit 来创造我的整合测试。在我们建立了名为 Chinook.IntegrationTest 的新 xUnit 测试专案之后，我们需要新增合适的 NuGet 包。将 Microsoft.AspNetCore.TestHost 包新增到 Chinook.IntegrationTest 专案中来。这个包中包含了执行整合测试的资源。

图 2：新增 Microsoft.AspNetCore.TestHost NuGet 包

接下来，我们可以建立第一个整合测试来从外部验证我们的 API。

建立第一个整合测试

要想进行我们解决方案中的所有 API 外部测试，我要建立一个名为 API 的资料夹，其中包含了测试。我还需要在 API 域中给每个实体型别建立新的测试类。我们的首个整合测试将会覆盖专辑实体型别。

在 API 资料夹中建立新的类 AlbumAPITest.cs。之后我们会在档案中新增如下的名称空间。

复制程式码

using Xunit;

using Chinook.API;

using Microsoft.AspNetCore.TestHost;

using Microsoft.AspNetCore.Hosting;

图 3：使用指令进行整合测试

现在我们要使用 TestServer 来设定类，使用 HttpClient 来执行测试。我们需要名为 _client，型别为 HttpClient 的私有变数，它是基于在 AlbumAPITest 类中的建构函式中初始化的 TestServer 而建立的。TestServer 是小型 web 服务器的包装器，是基于 Chinook.API Startup 和需要的开发环境建立的。在这个例子中，我使用开发环境。我们现在具备了执行 API 的 web 服务器，以及了解如何在 TestServer 中呼叫 API 的客户端。我们可以开始编写整合测试程式码了。

图 4：我们第一个整合测试，获得所有的专辑

除了建构函式程式码之外，图 4 中还展示了第一个整合测试的程式码。AlbumGetAllTestAsync 方法将会测试验证从 API 获取所有专辑的呼叫。就像之前讨论的单元测试一样，整合测试的逻辑也是用了 Arrange、Act 和 Assert。我们首先建立 HttpRequestMessage 物件，其中 HTTP 作为 InlineData 注释中的变数而提供，URI 部分表示对于所有的专辑的呼叫 (“/api/Album/”)。之后我们会让 HttpClient _client 传送 HTTP 请求，最后，我们会检查验证 HTTP 响应是否满足我们的期望，在本例中是 200。图 4 中我展示了两种检验 API 呼叫的方法。你可以使用其中任意一种，但我更喜欢第二种方法，因为它允许我用相同的模式来检验对特定 HTTP 响应程式码的响应。

复制程式码

response.EnsureSuccessStatusCode();

Assert.Equal(HttpStatusCode.OK, response.StatusCode);

我们还可以建立需要从 API 测试特定实体键的整合测试。对于这类测试，我们需要在 InlineData 注释中新增额外的值，将会通过 AlbumGetTestAsync 方法引数传递。我们的新测试会使用相同的逻辑，并使用和之前测试一样的资源，但是我们为 HttpRequestMessage 物件在 API URI 端中传递实体键。你可以在图 5 中检视程式码。

图 5：专辑的第二个整合测试

在你为测试 API 创造了所有整合测试之后，需要通过 Test Runner 来执行它们，并保证它们全部通过。你建立的所有测试也可以在 DevOps 持续整合（CI）过程中执行，这样可以在整体开发和部署过程中测试你的 API。现在需要有执行路径保证你的 API 在开发、质量保证和部署阶段都得到测试和维护，让你的 API 使用者拥有良好体验的同时不发生意外情况。