在 C# 課程中管理 CORS 和測試 - 構建一個範例 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<CourseModel>>() 撰寫了一個異步方法。

該方法硬編碼了當地API URL (4:00)，作為驗證前端和後端之間通信的簡單測試。

這裡沒有測試方法或錯誤處理，只有一個直接的呼叫。 此設置反映了編寫單元測試的早期步驟，您首先驗證元件之間的基本互動。

構建資料擷取邏輯和UI

在凌晨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 語法撰寫了一個簡單的 UI 迴圈來遍歷課程清單：

@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，但失敗了。 瀏覽器的主控台顯示了一個熟悉的訊息：

"從來源"[Frontend URL]"存取"[API URL]"已被CORS政策阻擋..."(7:02)

這就是了解和管理CORS變得至關重要的地方。 如果沒有適當的標頭，瀏覽器會阻止從一個來源到另一個來源的請求。

建立CORS配置類別

Tim沒有將程式碼塞在Program.cs中，而是在Startup資料夾中建立了一個名為CorsConfig的專用類別。 他使用靜態類別結構來套用與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 容器內測試 APIs 是理想的，特別是當開發者正在對真實端點進行實驗或撰寫單元測試時。

在 Program.cs 中整合配置

Tim在Program.cs中註冊CORS服務並應用配置：

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

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

這種模組化設計提升了程式碼品質，並使將來加入模擬框架或注入測試行為變得更容易。 它反映了您在C#中進行單元測試的結構，其中集中化配置可以簡化測試設置。

重新測試前端

在應用CORS修正之後，Tim重新運行這兩個應用程式。 這次，Blazor前端正常運作——課程資料成功載入，每個課程圖片連結到相關的URL。

重要的是，前端未做任何更改。 整個修復是在API層面完成的，通過正確的CORS配置。

測試和設置策略的課程

雖然 Tim 在這段影片中沒有直接深入單元測試框架，但他的做法為此奠定了基礎。 操作方法如下：

他能夠清楚地分離關注點，從而在未來可以使用測試類和模擬物件。

專用的CORS設定檔可以在測試期間重複使用或用模擬配置替換。

他的快速前端專案就像手動整合測試，在撰寫完整的單元測試專案之前進行早期驗證。

這就像您在Visual Studio中進行測試的方法：

建立一個單元測試專案與您的主要應用程式並行。

使用測試探索器來執行所有測試方法並追蹤結果。

模擬外部相依項，例如HTTP請求、資料庫呼叫或設定檔案。

撰寫簡單的單元測試來驗證預期行為，然後擴展以涵蓋具有邊界情況的測試案例。

CORS場景的單元測試考量

儘管Tim的影片主要關於配置CORS，但其對軟體測試的影響是清楚的：

您可以建立單元測試方法來驗證您的配置服務。

使用模擬框架，模擬不同來源或HTTP方法等外部因素。

將測試執行作為CI/CD流程的一部分，以確保您的測試方法能夠始終通過。

將測試整合到Visual Studio Test Explorer中以追蹤失敗並確保穩定性。

結論

在這個影片教學中，Tim Corey 提供了一個管理 C# Web API 中 CORS 的實際範例，同時構建了一個簡單的 Blazor 前端來測試連接性。 他的做法不僅僅是修復瀏覽器錯誤——它建立了一個結構，鼓勵可維護的程式碼、清晰的架構，並且易於擴展到自動化測試。

從這裡開始，開發者可以充滿信心地進行單元測試的編寫、設置整合測試，並使用像Visual Studio、Test Explorer和模擬框架這樣的工具來提高程式碼的質量和可靠性。

無論您正在學習如何開始測試、撰寫第一個單元測試，還是確保測試方法在預期情況下失敗，本課程都為強大的開發過程提供了基礎。 最重要的是，一切都從獲得正確的架構和配置開始。