スローダウンとエラーコードの追加 - C#でサンプルAPIを構築するコース

Tim Corey

16 分 21 秒

最新のアプリケーション、特にウェブフロントエンドを持つアプリケーションを構築しテストする際、開発者はAPIの遅延や予期せぬエラー応答のような実世界のシナリオをシミュレートする必要性にしばしば直面します。 これをサポートするために、ティム・コーリーは"スローダウンとエラーコードの追加 - C#でサンプルAPIを構築する"と題したコースレッスンで、非常に実践的なウォークスルーを紹介しています。 このビデオでティムは、テスト中に理想的でない状況をシミュレートするための貴重なツールである人工的な遅延とカスタムエラーレスポンスで最小限のC# APIを豊かにする方法を説明します。

この記事では、ティムがビデオで示したコンセプトと実装について説明します。

サンプルAPIの紹介とその目的

Timはレッスンの冒頭で、Web開発を学ぶ際にサンプルAPIを持つことの価値を繰り返し説明します。 このようなAPIは、あなたのフロントエンド・アプリケーションをテストするための具体的な何かを与えてくれます。

コース終了までに、Timは以下を含む堅牢なAPIを構築することを目指しています：

• サンプルデータ

• ドキュメンテーション

• ヘルスチェック

• 速度低下のシミュレーション

• 模擬エラー

• DockerとVPSによるデプロイメントオプション

この具体的なレッスンでは、Timは、速度低下のシミュレーションと、悪条件下での現実的なAPIの動作のためのエラーコードの生成に重点を置いています。

APIエンドポイントに人工的な遅延を追加する

Timは、特定のAPIエンドポイント、特にコースデータを扱うAPIエンドポイントに、オプションのdelayパラメータを追加することから始めます。 彼の目標は、より良いフロントエンドのテストのために、遅いAPI応答をシミュレートすることです。

実装の詳細：

• delayパラメータはミリ秒を表すnull可能な整数です。

• これを処理するために、Timはエンドポイントメソッドを、単なるIResultの代わりにTask<IResult>を返す非同期メソッド（async）に移行します。

• 遅延が提供され、許容範囲内（300,000ミリ秒または5分を超えない）である場合、メソッドは実行を一時停止するためにTask.Delay()を呼び出します。

2:33で、ティムは遅延を抑えることの重要性を強調しています。 彼は、アプリケーションが応答しなくなったり、壊れているように見えるような不合理な待ち時間を防ぐために、上限を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)

この追加により、開発者は5分までの遅延をシミュレートできるようになり、クライアント・アプリケーションでのタイムアウトや応答性のテストに役立ちます。

遅延メカニズムをテストする

TimはPostman（またはPostmanのクローン）を使っていくつかのテストを実行し、遅延ロジックを検証します。 例えば：

• delay=5000（5秒）は、結果を返す前にAPIを一時停止させます。

• delay=500にすると、間が短くなります。

彼は、実際の遅延は、処理のオーバーヘッドにより、指定された値よりも常にわずかに長くなることを観察しています。 Timが5:09で述べているように、APIをミリ秒単位でタイミングをとるのではなく、閾値をシミュレートするのです。

遅延機能をより多くのエンドポイントに拡張する

ティムは、"すべてのコースを読み込む"エンドポイントだけにとどまりません。 彼は一貫性を望んでいるので、"load course by ID "エンドポイントに同じ遅延機能を実装します。

6:15で、非同期への変換時にメソッド名に"Async"が自動的に追加されることによる命名の衝突という問題にぶつかります。 Timは、両方のメソッド名をAsync命名規則に合わせて調整し、明快さと一貫性を保っています。

テストで実装を確認します：

• 納期は厳守します。

• 存在しないレコードは、遅延後に期待どおりに404を返します。

• 遅延の削除や空の値の受け渡しは適切に動作し、TimはAPI自体の問題ではなく、PostmanのUIの癖を指摘している（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()を介してこの新しいエンドポイントをプログラムに追加し、エラークラスをstaticとしてマークしています。

エラー エンドポイントのテスト

Tim は今、さまざまなステータス・コードを渡してエラー・エンドポイントをテストしています：

• 400 は "Bad Request" を返します。

• 401 は "Unauthorized" を返します。

• 404 は "Not Found" を返します。

• 301 は "Moved Permanently" を返します。

• 405 は "Method Not Allowed" を返します。

これは、エラーコードだけでなく、あらゆるHTTPステータスコードに対するエンドポイントの柔軟性を示しています。 13:04で、Timはこのアプローチがフロントエンドアプリが異なるサーバーレスポンスをどのように扱うかをテストするのに理想的であることを確認しています。

彼は/httpcodeという名前も考えたが、主にエラー状態をシミュレートするために使用されるため、シンプルに/errorにこだわった。

機能強化の概要

ティムは、APIに加えられた改善点を要約してビデオを締めくくります：

• スローダウンは、APIレスポンスにおける現実世界の待ち時間をシミュレートします。

• エラーシミュレーションは、事実上どんなHTTPレスポンスに対してもテストできる柔軟性を提供します。

• これらの機能により、サンプルAPIはより堅牢になり、現実的なテストシナリオにとって貴重なものとなります。

14:16で、Timは、遅延応答やさまざまなサーバーエラーなど、さまざまなAPIの状態下でアプリがどのように動作するかをテストするための、これらのツールの重要性を強調しています。

次へ：APIをドッキングする

このビデオでは詳しく説明されていませんが、ティムは次のステップを示唆しています：APIをDocker化する。 これにより、開発者は自己完結型のDockerコンテナでサンプルAPIをローカルに実行することができ、異なる環境でのデプロイや共有が容易になります。

最終的な考え

Timは、開発者が実際にテストする必要のある現実的な機能を含む包括的なサンプルAPIを構築することへのコミットメントを繰り返し、ビデオを締めくくります。これには以下が含まれる：

• 遅延

• エラー

• ヘルスチェック

• 認証と高度なエンドポイントに関する今後の計画

目標はシンプルですが、強力です。実際のAPIの癖を模倣したツールを開発者に提供することで、アプリケーションを堅牢で、信頼性が高く、ユーザーフレンドリーにすることです。

結論

このレッスンが終わるころには、視聴者はAPIに人為的な遅延やエラー応答を導入する方法と理由をよりよく理解できるようになっています。ティム・コーリーのアプローチは理路整然としており、実践的で、実際のアプリケーションテストのニーズに直接結びついています。 APIテストを強化したいのであれば、このレッスンは優れたリソースです。

ティム・コーリーによるビデオレッスンで、実践的なガイダンスをご覧ください。