CORSの管理とテスト - C#でサンプルAPIを構築するコース
C#でWeb APIを使用する場合、CORS(Cross-Origin Resource Sharing:クロスオリジンリソース共有)が障害になることがよくあります。 最近のソフトウェア開発では、APIがBlazor WebAssembly、Angular、Reactのようなフロントエンドクライアントにサービスを提供するのが一般的なシナリオです。
Managing CORS and Testing - Building a Sample API in C# Course"のビデオチュートリアルでは、Tim Corey 氏がサンプル API を構築してテストしながら、CORS を効果的に管理する方法を実演しています。 このアプローチは、開発者がクロスオリジンの問題を修正するだけでなく、単体テスト、統合テスト、自動化ワークフローなど、より高度なテスト技術に備えるのに役立ちます。
それでは、ビデオに飛び込んで、ティムのガイダンスに従ってステップ・バイ・ステップで進めていきましょう。
Blazorフロントエンドのセットアップ
Tim は、SampleTestUI という名前の単純な Blazor WebAssembly フロントエンドプロジェクトを作成することからレッスンを始めます。 このフロントエンドは本番用ではなく、APIとの接続性を検証し、意図的にCORSの問題を引き起こすためのテストプロジェクトです。
Timは.NET 9のテンプレートを使用し、認証やPWA機能はオプトアウトしています。
フロントエンドの目的は、実際のAPIコールをシミュレートし、クロスオリジンリクエストに関連するテストの失敗を公開することです。
- 彼は、/courses APIエンドポイントを呼び出し、関連する画像とともにコースのリストを表示するようにホームページを修正します。
フロントエンドは、APIとモデルを共有するのではなく、個別に作成されたシンプルなモデルクラス(CourseModel)を使用します。 Timは、結合を減らし保守性を高めるために、フロントエンドモデルはデータアクセスモデルから分離すべきだと強調している(2:28)。 これは、保守可能なテストとテスト可能なコードを書くときの重要な原則です。
APIコールの記述
APIからデータを取得する:
Tim は HttpClient を注入します。
彼は、Http.GetFromJsonAsync<List
>() を使って非同期メソッドを書きます。 - このメソッドは、ローカル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> }各コースは、ハイパーリンクに包まれた画像として表示されます。 ティムは、画像が大きい(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構成クラスを作成する
Program.csを乱雑にするのではなく、ティムはStartupフォルダにCorsConfigという専用のクラスを作成します。 SwaggerやOpenAPIのセットアップに使われるのと同じ設定パターンを適用するために、静的クラス構造を使用している。
これは、クリーンコードのプラクティスと一致し、アプリケーションをよりテストしやすくします。 このようなモジュラー構成は、ロジックが分離され、モックやオーバーライドが容易になるため、後でユニットテストメソッドを書くのも容易になります。
寛容な CORS ポリシーを適用する
Timは、完全なクロスオリジンアクセスを可能にするために、非常にオープンなCORSポリシーを定義しています:
policy.AllowAnyOrigin().AllowAnyMethod().AllowAnyHeader();policy.AllowAnyOrigin().AllowAnyMethod().AllowAnyHeader();この設定は、外部サービスやフロントエンドアプリがAPIにフルアクセスする必要があるテスト駆動開発や統合テストに役立ちます。 ティムはこのポリシーを"AllowAll"と呼び、タイプミスや矛盾を防ぐために名前を定数に保存している(11:00):
private const string AllowAllPolicy = "AllowAll";private const string AllowAllPolicy = "AllowAll";彼は、これは本番で使うべきでないが、開発者が実際のエンドポイントに対して実験したり、ユニットテストを書いたりしているローカルやDockerコンテナ内でAPIをテストするのに理想的だと指摘している。
Program.csに設定を統合する
TimはCORSサービスを登録し、Program.csで設定を適用する:
builder.Services.AddCorsServices(); app.ApplyCorsConfig();builder.Services.AddCorsServices(); app.ApplyCorsConfig();このモジュール化により、コードの品質が向上し、将来的にモッキングフレームワークを追加したり、テストビヘイビアを注入したりすることが容易になります。 C#のユニットテストでは、一元化されたコンフィギュレーションがテストのセットアップを簡素化します。
フロントエンドの再テスト
CORSの修正を適用した後、Timは両方のアプリケーションを再実行します。 今回、Blazorフロントエンドは期待通りに動作し、コースデータは正常にロードされ、各コース画像は関連するURLにリンクしています。
重要なのは、フロントエンドに変更を加えないことです。 修正はすべてAPIレベルで行われ、適切なCORSコンフィギュレーションを通して行われました。
テストとセットアップ戦略のレッスン
ティムはこのビデオでユニットテスト・フレームワークに直接飛び込んではいませんが、彼のアプローチはそのための基礎を作っています。 以下の方法です:
彼は、将来的にテストクラスやモックオブジェクトを使用できるように、懸念をきれいに分離します。
専用のCORSセットアップファイルは、テスト中に再利用したり、モック構成に置き換えたりすることができる。
- 彼の迅速なフロントエンド・プロジェクトは、完全なユニットテスト・プロジェクトを書く前の初期の検証である、手動の統合テストのような役割を果たします。
これは、Visual Studioでのテストにどのようにアプローチするかを反映しています:
メインのアプリケーションと並行して、ユニットテストプロジェクトを作成してください。
Test Explorer を使用して、すべてのテストメソッドを実行し、結果を追跡します。
HTTPリクエスト、データベース呼び出し、設定ファイルなどの外部依存関係を模擬します。
- 期待される動作を検証するために簡単な単体テストを記述し、その後、エッジ条件を含むテストケースをカバーするように拡張します。
CORSシナリオのユニットテストに関する考察
Tim のビデオは主に CORS の設定についてですが、ソフトウェアテストへの影響は明らかです:
コンフィギュレーション・サービスを検証するユニット・テスト・メソッドを作成することができます。
モッキングフレームワークを使用して、異なるオリジンやHTTPメソッドなどの外部要因をシミュレートします。
CI/CDプロセスの一環としてテスト実行を行い、テストメソッドが一貫してパスすることを確認してください。
- Visual Studio のテストエクスプローラーにテストを組み込み、障害を追跡して安定性を確保します。
結論
この ビデオ チュートリアルでは、Tim Corey が、接続性をテストするためのシンプルな Blazor フロントエンドを構築しながら、C# Web API で CORS を管理する実践的な例を提供します。 彼のアプローチは、単にブラウザのエラーを修正するだけでなく、保守可能なコード、クリーンなアーキテクチャ、自動テストへの容易な拡張を促進する構造を設定します。
ここから、開発者は自信を持って単体テストの記述、統合テストの設定、Visual Studio、Test Explorer、モッキングフレームワークなどのツールの使用に進み、コードの品質と信頼性を向上させることができます。
テストの開始方法、最初の単体テストの書き方、テストメソッドが期待通りに失敗することを確認する方法など、このレッスンは強力な開発プロセスの基礎を提供します。 そして最も重要なことは、アーキテクチャと構成を正しく理解することから始まります。


