在 C# 課程中為範例 API 新增延時和錯誤碼

Tim Corey

16m 21s

在建置和測試現代應用程式時，特別是那些具有網頁前端的應用，開發者經常需要模擬現實世界情境，如API延遲和意外的錯誤回應。 為了支援這一點，Tim Corey在他的課程中提供了一個非常實用的演練，課程名稱為"Adding Slowdowns and Error Codes - Building a Sample API in C#"。 在此影片中，Tim闡述了如何使用人工延遲和自定義錯誤回應來豐富一個小型C# API，這些都是在測試期間模擬不理想情況的寶貴工具。

在本文中，我們將帶您了解影片中Tim所展示的概念和實施。

範例API和其目的介紹

Tim在課程開始時重申了當學習網頁開發時有一個範例API的價值。 這樣的API能讓您有一個具體的東西來測試您的前端應用程式。

課程結束時，Tim的目標是建置一個包含以下內容的強大API：

• 範例資料

• 文件

• 健康檢查

• 模擬延遲

• 模擬錯誤

• 通過Docker和VPS的部署選項

在這節特定的課程中，Tim專注於模擬延遲和產生錯誤程式碼，以便在不利條件下實現現實的API行為。

在API端點中新增人工延遲

Tim先在特定的API端點——特別是處理課程資料的那些，新增一個可選的延遲參數。 他的目標是模擬緩慢的API回應，以便更好地進行前端測試。

實施細節：

• 延遲參數是一個可為空的整數，代表毫秒數。

• 為了應對這一點，Tim將端點方法轉換為非同步方法（async），返回Task<IResult>而不僅是IResult。

• 如果提供了延遲並且在可接受的範圍內（不超過300,000毫秒或5分鐘），該方法將調用Task.Delay()來暫停執行。

在2:33，Tim強調了限制延遲的重要性。 他將上限設置為5分鐘，以防止造成不合理的等待時間，這可能會使應用程式無法回應或顯示為故障。

if (delay > 300000)
{
    delay = 300000;
}
await Task.Delay(delay.Value);

if (delay > 300000)
{
    delay = 300000;
}
await Task.Delay(delay.Value);

If delay > 300000 Then
    delay = 300000
End If
Await Task.Delay(delay.Value)

If delay > 300000 Then
    delay = 300000
End If
Await Task.Delay(delay.Value)

這一新增確保開發者可以模擬長達五分鐘的延遲，這對於測試超時和客戶端應用程式的回應性非常有用。

測試延遲機制

Tim使用Postman（或Postman克隆工具）運行了一些測試來驗證延遲邏輯。 例如：

• 延遲=5000（5秒）導致API在返回結果前暫停。

• 延遲=500導致較短的暫停。

他注意到，由於處理的開銷，實際延遲總會稍微長於指定值——這是一個重要的現實世界細節。 正如Tim在5:09指出的，您不是精確地計時API到毫秒，而是模擬一個閾值。

將延遲功能擴展到更多端點

Tim並不止步於"載入所有課程"端點。 為了保持一致性，他在"通過ID載入課程"端點中實施了相同的延遲功能。

在6:15，他遇到了一個障礙：由於將方法轉換為非同步時自動新增了"Async"而導致的命名衝突。 Tim調整了兩個方法名稱，以符合Async命名約定，提高清晰度和一致性。

測試確認了實施：

• 延遲受到尊重。

• 在延遲後，非存在的記錄按預期返回404。

• 移除延遲或傳遞空值會正常行為，Tim指出這是一個Postman的UI怪癖，而不是API本身的問題（8:00）。

新增自定義錯誤回應

接下來，Tim介紹了一個對API測試來說非常有價值的工具：一個專用端點，可以模擬各種HTTP錯誤程式碼。

在9:13，他解釋說，雖然某些端點（如返回ID課程的端點）自然會為缺少資料返回404，但沒有內建的方法來測試其他錯誤程式碼——除非明確模擬。

Tim在/error/{code}上建立了一個新端點，它：

• 接受一個整數HTTP狀態碼。

• 使用switch表達式返回相應的HTTP錯誤回應。

code switch
{
    400 => Results.BadRequest(),
    401 => Results.Unauthorized(),
    403 => Results.Forbid(),
    404 => Results.NotFound(),
    _   => Results.StatusCode(code)
};

code switch
{
    400 => Results.BadRequest(),
    401 => Results.Unauthorized(),
    403 => Results.Forbid(),
    404 => Results.NotFound(),
    _   => Results.StatusCode(code)
};

Select Case code
    Case 400
        Results.BadRequest()
    Case 401
        Results.Unauthorized()
    Case 403
        Results.Forbid()
    Case 404
        Results.NotFound()
    Case Else
        Results.StatusCode(code)
End Select

Select Case code
    Case 400
        Results.BadRequest()
    Case 401
        Results.Unauthorized()
    Case 403
        Results.Forbid()
    Case 404
        Results.NotFound()
    Case Else
        Results.StatusCode(code)
End Select

這涵蓋了常見的客戶端錯誤以及開發者可能希望測試的任何自定義程式碼。

在12:03，他將這個新端點通過app.AddErrorEndpoints()新增到程式中，並將錯誤類別標記為靜態的。

測試錯誤端點

Tim現在通過傳遞各種狀態碼來測試錯誤端點：

• 400返回"不正當的要求"

• 401返回"未經授權"

• 404返回"找不到"

• 301返回"永久移動"

• 405返回"方法不允許"

這顯示了該端點的靈活性——不僅適用於錯誤程式碼，還適用於任何HTTP狀態碼。 在13:04，Tim確認這種方法是理想的選擇，用於測試前端應用程式如何處理不同的伺服器回應。

雖然他考慮過將其命名為/httpcode，但為了簡單，他堅持使用/error，因為它主要用於模擬錯誤情況。

功能增強總結

Tim總結了影片中對API的改進：

• 延遲模擬API回應中的現實世界延遲。

• 錯誤模擬提供了靈活性，可以測試幾乎任何HTTP回應。

• 這些功能使範例API更加健壯，對於現實測試情境尤為珍貴。

在14:16，Tim強調這些工具對於測試您的應用在不同API狀態下的行為（例如延遲回應或各種伺服器錯誤）有多重要。

接下來的步驟：將API容器化

儘管在此影片中沒有詳細介紹，Tim暗示了下一步：將API容器化。 這使得開發者可以在本地運行這個樣例API，使用一個自包含的Docker容器，這使得在不同環境中部署和共享更加容易。

最後的想法

Tim在影片結尾重申了他對建立一個包含開發者實際需要測試的現實特徵的完整樣例API的承諾。其中包括：

• 延遲

• 錯誤

• 健康檢查

• 針對未來的身份驗證和高級端點的計畫

目標簡單而強大——為開發者提供一個模擬真實API怪癖的工具，從而使他們的應用程式堅固、可靠和使用者友好。

結論

通過完成本課程，觀眾對於如何以及為什麼要在他們的API中引入人工延遲和錯誤回應有了更好的理解。Tim Corey的方法是有條理的、實用的，並且直接與現實世界的應用測試需求相關聯。 如果您想提升您的API測試技術，這門課程是一個值得遵循的出色資源——而現在您確切知道該去哪裡尋找。

觀看Tim Corey的完整影片課程，獲得實用指導。