Web API コントローラーで統合テストを行いたいと考えています。統合テストが開始されると、Web API の要求/応答パイプライン全体が処理され、実際の統合テストになります。
非 InMemory テストまたは InMemory テストに関するいくつかのブログを読みました。私は違いが何であるかを知る必要があり、それらのアプローチのどれが私の上記の基準に一致しますか?
セルフホスティングまたはIISホスティングのWeb APIでの統合テストを実際に扱った人々からの説明が本当にうれしいです（テストに違いがある場合...）
非インメモリ テストの意味がわかりませんが、インメモリ ホスト Web API を含む統合テストでは、要求は に直接送信されますHttpServer。これは基本的に、ASP.NET Web API パイプラインで実行される最初のコンポーネントです。これは、リクエストがネットワーク スタックにヒットしないことを意味します。したがって、特定のポートなどで実行することを心配する必要はありません。また、十分な量のテストを記述した場合、すべてのテストを実行するのにかかる時間はそれほど大きくありません。通信網。通常の単体テストと同等の実行時間が得られるはずです。インメモリ テストの詳細については、Kiran によるこの優れた投稿を参照してください。インメモリ テストでは、パイプラインで実行するように設定したすべてのコンポーネントが実行されますが、注意すべき点の 1 つはフォーマッターです。送ればObjectContentリクエストでは、メディア フォーマッタを実行する必要はありません。これは、リクエストが既にデシリアライズされたフォーマットであり、メディアのフォーマットが行われないためです。
もっと近づき、実行時間を短縮したい場合は、セルフホストを使用してテストを作成できます。それは、非インメモリ テストの意味ですか? 例として、OWIN セルフホスティングを使用できます。Katana ホスティング API を使用して Web API をホストし、リクエストをヒットさせることができます。もちろん、これは実際の HttpListener を使用し、リクエストはネットワーク スタックを通過しますが、それはすべて同じマシンで行われます。テストは比較的遅くなりますが、おそらく製品の実行にかなり近づきます。
個人的には、Web ホスティングを使用して多くの統合テストを行っている人を見たことがありません。技術的にはHttpClient、応答を使用して検査し、内容をアサートすることは可能ですが、プログラムでテストを調整することはあまり制御できません。
つまり、可能な限りメモリ内テストを使用し、実際にネットワークにアクセスする必要がある特定のケースにのみ Katana ベースのホストを使用します。