HttpContext が構築できるのに、なぜモックする必要があるのでしょうか?
-
18-09-2019 - |
質問
私は常に ASP.NET で何らかの方法で HttpContext を偽装/モック/スタブ化してきました (ASP.NET MVC/MonoRail でははるかに簡単です)。
しかし、HttpContext 自体は文字通り数行のコードで簡単に構築できることがわかります。
var tw = new StringWriter();
var workerReq = new SimpleWorkerRequest("/webapp", @"c:\here\there\wwwroot", "page.aspx", tw);
var context = new HtpContext(workerReq);
このコードを次のようなものにラップすると、うまく動作するはずです。おそらく、それを使用して ASPX をレンダリングすることもできます。
using(Simulate.HttpContext()) {
HttpContext.Current.BlaBla;
}
したがって、質問は次のとおりです。
- それをしてはいけない理由。
- それを行うべき理由。
- なぜそれが広く使用されないのか(実際、私はそれに関する投稿をまったく覚えていません)。
Phill Haack が Reflection ハックを使用して HttpContext を構築したという 1 つの投稿を覚えています。
しかし、それは単に必要ではないようです。
乾杯、
ドミトリー。
解決
これは非常に簡単なテストを行うための罰金ですが、どのようにユニットHttpRequest.Filesを使用するコンポーネントをテストするのでしょうか?私の知る限りでは、あなたがSimpleWorkerRequestでこれを指定することを可能にする全くパブリックAPIはありません。あなたはHttpFileCollectionプロパティを設定することができた場所を見つけることができたとしても、そのコンストラクタが内部であることに注意してくださいので、あなたも、その型のインスタンスを作成することはできません。
HttpRequest.Filesはこの点だけではなく、実際には、を大幅より多くのものは、おそらくありますすることができません。のテストは、をより現在のHttpContextの実装とすることができます。のテスト。抽象化は本当に便利になるところです。
他のヒント
考慮すべきシナリオのカップルがあります。
シナリオ1:あなたはユニットテストです。あなたは、キャッシュへのアクセスを管理するクラスのように、小さな何かを持っている、そしてそれは、明示的にHttpContent.Cacheを呼び出します。あなたは呼び出しが行われているかを見ることができますので、この場合は、コンテキストを嘲笑し、かどうか、彼らはあなたが期待WYを作業しています。
シナリオ2:あなたは、複雑なページを生成するような大規模なものをテストしようとしている統合テストを、やっています。この場合、オブジェクトそれをあなたが見つけた道をHttpContent本物を与えます。あなたの統合テストは、より良い本物のランタイムをシミュレートします。
それはうまくいくかもしれませんが...
- まず、環境によって異なる可能性のあるいくつかのパスが表示されます。
- 次に、IIS のようなものがインストールされている必要がありますか?
- 作成にはどのくらい時間がかかりますか?必要なテストが 100 件あり、それに 1 秒かかる場合、テストの実行時間が約 1 分以上長くなり、開発者のテスト実行時間が短縮されることになります。
- テストシナリオを作成するためのキャッシュ、リクエストなどのモック/設定をどの程度簡単に行うことができますか?
モッキング/スタブ化はおそらく簡単です。
編集
Mono プロジェクトで HttpContext と SimpleWorkerRequest のソース コードが見つかりました。
これらは創造の世界で何が起こっているのかをより良く洞察することができます。
同様に役立つかもしれない記事を見つけました: ASP.NET CreateApplicationHost/SimpleWorkerRequest API ホール
これは実際、オブジェクトを適用する前にそれらのオブジェクトで何が起こっているのかを理解する必要があり、それには時間がかかることをよく示しています。嘲笑するのは簡単なようです。