管理 CORS 和测试 - 用 C# 构建示例 API 课程

设置 Blazor 前端

Tim 在课程开始时创建了一个名为 SampleTestUI 的简单 Blazor WebAssembly 前端项目。 该前端并非生产就绪，而是一个测试项目，用于验证与 API 的连接性，并故意触发 CORS 问题。

• Tim 使用 .NET 9 模板，并选择不使用身份验证或 PWA 功能。

• 前端的目的是模拟真实世界的 API 调用，并暴露与跨源请求相关的测试失败。

• 他修改了主页，以调用 /courses API 端点并显示课程列表及相关图片。

前端使用单独创建的简单模型类（CourseModel），而不是与 API 共享模型。 Tim 强调前端模型应与数据访问模型分开，以减少耦合并提高可维护性（2:28）。 这是编写可维护测试和可测试代码的重要原则。

编写 API 调用

从 API 获取数据：

• Tim 注入了一个 HttpClient。

• 他使用 Http.GetFromJsonAsync<List>() 编写了一个异步方法。

• 该方法使用本地 API URL 进行硬编码（4:00），作为验证前端和后端之间通信的简单测试。

这里没有测试方法或错误处理，只是直接调用。 这种设置反映了编写单元测试的早期步骤，即从验证组件之间的基本交互开始。

构建数据获取逻辑和用户界面

在 4:00 硬编码 API URL 后，Tim 将重点放在构建核心逻辑上，以便从 API 获取课程数据并将其显示在 Blazor 前端。 这是在编写自动测试或使用测试框架之前验证前端是否能与后台交互的关键步骤。

首先，他要确保从 API 的 launchSettings.json 中使用正确的 URL--抓取 HTTPS 地址并附加 /courses 以形成完整的端点。 这一点非常重要，因为浏览器通常会拒绝从安全页面调用非 HTTPS API。

courses = await Http.GetFromJsonAsync<List<CourseModel>>("https://localhost:port/courses");

courses = await Http.GetFromJsonAsync<List<CourseModel>>("https://localhost:port/courses");

显示数据

获取数据后，Tim 使用 Razor 语法编写了一个简单的用户界面循环，以遍历课程列表：

@foreach (var c in courses) { <a href="@c.CourseUrl"> <img width="300" src="@c.CourseImage" /> </a> }

@foreach (var c in courses) { <a href="@c.CourseUrl"> <img width="300" src="@c.CourseImage" /> </a> }

每门课程都以图片形式显示，并用超链接封装。 Tim 注意到图片很大（1920x1080），因此他将宽度限制在 300px，以避免页面过大。

该输出可作为 API 数据正确流入前端的可视化确认。 它模仿了测试方法通过时的反馈--如果图片显示出来，说明请求成功。

准备发布

在运行应用程序之前，Tim 在 Visual Studio 中配置了多个启动项目。 他设定 API 项目首先启动，然后是 Blazor 前端。 这一顺序对于确保 API 在前端尝试获取数据时准备就绪至关重要。

6:30 的最后一步为运行测试和遇到 CORS 错误奠定了基础，这也是教程下一部分的开始。

撞上 CORS 墙

当 Tim 使用 Visual Studio 的解决方案资源管理器同时启动两个项目时，前端试图调用 API 但失败了。 浏览器控制台显示一条熟悉的信息：

"由于 CORS 策略，从原点'[前端 URL]' 访问'[API URL]' 获取数据的行为已被阻止......"(7:02)

这就是理解和管理 CORS 的关键所在。 如果没有适当的标头，浏览器就会阻止从一个来源向另一个来源的请求。

创建 CORS 配置类

Tim 在启动文件夹中创建了一个名为 CorsConfig 的专用类，而不是将 Program.cs 放得杂乱无章。 他使用静态类结构来应用与 Swagger 和 OpenAPI 设置相同的配置模式。

这符合简洁代码实践，并使应用程序更具可测试性。 像这样的模块化配置还能让以后编写单元测试方法变得更容易，因为逻辑是孤立的，更容易模拟或覆盖。

应用许可 CORS 政策

Tim 定义了一个非常开放的 CORS 策略，允许完全的跨源访问：

policy.AllowAnyOrigin().AllowAnyMethod().AllowAnyHeader();

policy.AllowAnyOrigin().AllowAnyMethod().AllowAnyHeader();

这种设置在测试驱动开发和集成测试中非常有用，因为在这些测试中，外部服务或前端应用程序需要完全访问 API。 Tim 将此策略称为 "AllowAll"，并将名称存储在常量中，以防止错字和不一致（11:00）：

private const string AllowAllPolicy = "AllowAll";

private const string AllowAllPolicy = "AllowAll";

他指出，这不应该在生产中使用，但它非常适合在本地或 Docker 容器内测试 API，开发人员可以在其中进行实验或针对实际端点编写单元测试。

将配置整合到 Program.cs 中

Tim 在 Program.cs 中注册 CORS 服务并应用配置：

builder.Services.AddCorsServices(); app.ApplyCorsConfig();

builder.Services.AddCorsServices(); app.ApplyCorsConfig();

这种模块化可提高代码质量，并使将来添加模拟框架或注入测试行为变得更加容易。 它反映了在 C# 中进行单元测试时的结构，集中配置可以简化测试设置。

重新测试前端

应用 CORS 修复后，Tim 重新运行了两个应用程序。 这一次，Blazor 前端如期运行--课程数据加载成功，每张课程图片都链接到了相关的 URL。

重要的是，不能对前端进行任何改动。 通过正确的 CORS 配置，整个修复工作发生在 API 层。

测试和设置策略课程

虽然 Tim 在这段视频中没有直接深入单元测试框架，但他的方法为单元测试框架奠定了基础。 这是怎么做的：

• 他干净利落地分离了关注点，以便将来使用测试类和模拟对象。

• 专用 CORS 设置文件可以重复使用，也可以在测试过程中用模拟配置代替。

• 他的快速前端项目就像一个手动集成测试，是编写完整单元测试项目之前的早期验证。

这与您在 Visual Studio 中的测试方法如出一辙：

• 在创建主应用程序的同时创建一个单元测试项目。

• 使用测试资源管理器运行所有测试方法并跟踪结果。

• 模拟 HTTP 请求、数据库调用或配置文件等外部依赖关系。

• 编写简单的单元测试来验证预期行为，然后扩展到包含边缘条件的测试用例。

CORS 场景的单元测试注意事项

虽然 Tim 的视频主要是关于 CORS 的配置，但对软件测试的影响也是显而易见的：

• 您可以创建单元测试方法来验证您的配置服务。

• 使用模拟框架模拟外部因素，如不同的起源或 HTTP 方法。

• 作为 CI/CD 流程的一部分运行测试执行，以确认您的测试方法始终如一地通过。

• 将测试纳入 Visual Studio 测试资源管理器，以跟踪故障并确保稳定性。

结论

在本 视频教程中，Tim Corey 提供了一个在 C# Web API 中管理 CORS 的实用示例，同时构建了一个简单的 Blazor 前端来测试连接性。 他的方法不仅仅是修复浏览器的错误，而是建立一种结构，鼓励可维护的代码、简洁的架构和易于扩展的自动化测试。

从这里开始，开发人员可以自信地编写单元测试、设置集成测试，并使用 Visual Studio、Test Explorer 和 mocking 框架等工具来提高代码质量和可靠性。

无论您是要学习如何开始测试、编写第一个单元测试，还是要确保测试方法在预期情况下失败，本课程都将为您提供一个强大的开发流程基础。 最重要的是，一切都要从正确的架构和配置开始。