管理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 語法編寫一個簡單的 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策略阻止...

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

建立CORS設定類別

Tim在Startup資料夾中創建了一個名為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。

最重要的是，前端沒有做任何更改。 整個修正是在API層級透過正確的CORS配置完成的。

測試和設置策略的課程

雖然Tim在這段影片中不直接探討單元測試框架，但他的方式為此奠定了基礎。 以下是方法：

他清楚地分離了關注點，使未來能使用測試類別和模擬物件。

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

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

這反映了您在Visual Studio中進行測試的方法：

在您的主應用程式旁建立一個單元測試專案。

使用 Test Explorer 來執行所有測試方法並追蹤結果。

模擬外部相依性，如HTTP請求、資料庫調用或配置檔案。

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

CORS場景的單元測試考量

雖然Tim 的影片主要是關於配置CORS，但對於軟體測試的影響是明顯的：

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

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

在您的CI/CD過程中執行測試執行，以確認您的測試方法能夠一致通過。

將測試納入Visual Studio Test Explorer中，以追蹤失敗並確保穩定性。

結論

在這個視頻教程中，Tim Corey 提供了一個在 C# Web API 中管理 CORS 的實際範例，並建立一個簡單的 Blazor 前端來測試連接。 他的做法不僅僅是解決瀏覽器錯誤，它還建立了一個結構，促使可維護的程式碼、清晰的架構和容易擴展到自動化測試中。

從這裡開始，開發者可以自信地前進，進行單元測試編寫、整合測試設置，並使用Visual Studio、Test Explorer和模擬框架等工具來提升程式碼品質和可靠性。

無論您正在學習如何開始測試、編寫您的第一個單元測試，還是確保測試方法在預期時失敗，本課程都為穩健的開發過程提供了基礎。 最重要的是，所有的一切都始於正確的架構和配置。