私はしばらく ASP.NET(WebForm) を使用してきましたが、ASP.NET MVC は初めてです。私が読んだ多くの記事から、ほとんどの場合、コントローラーのテストが難しい理由は、コントローラーがランタイム コンポーネント HttpContext (Request、Response ... を含む) にアクセスしているためです。コントローラーで HttpContext にアクセスするのは悪いようです。
ただし、これらのコンポーネントにどこかでアクセスし、Request から入力を読み取り、Response を介して結果を送り返し、Session を使用していくつかの状態変数を保持する必要があります。
コントローラーでアクセスしない場合、これらのランタイム コンポーネントにアクセスするのに最適な場所はどこでしょうか?
コントローラーでモデル メソッドを呼び出すと、Request オブジェクトと Response オブジェクトは同じ値を運ぶか、同じソースに出力します。これらのオブジェクトにとって重要なのは「ページ」です。
もう 1 つRequest、SessionおよびResponseオブジェクトはモデルで直接参照されない可能性があるため、 を使用System.Web.HttpContext.Currentしてオブジェクトを取得できます。これらは、コントローラーから呼び出されたものと同じように機能します。
また、コントローラーはビューとモデルの間のブリッジとして機能することを意図しており、モデルはこれらのオブジェクトに応答または要求の値がなくても機能する必要があるため、これらのオブジェクトの値を参照する代わりに、メソッドをモデル化する通常のパラメーターとして使用しますモデルの内部。これは MVC コンセプトの正しい使い方です。
コントローラーからこれらのオブジェクトに本当にアクセスする必要がある場合は、それらを抽象化し、それらのモック インスタンスを挿入して、テストをコントローラーだけに分離することができます。
MVC では、HttpContext は実際には HttpContextBase です。これらのクラスを直接使用しても問題ありません。後でコントローラーをテストする必要がある場合は、これらのクラスを非常に簡単にモックできます。
http://www.hanselman.com/blog/ASPNETMVCSessionAtMix08TDDAndMvcMockHelpers.aspx
あなたがやりたいことには何の問題もありません。
コントローラーで HttpContext にアクセスするのは悪いようです。
いいえ、そうではありません。自分の行動をどのようにテストするかを考える必要があるだけです。テストしなくても、おそらく問題はありません。ただし、テストすることをお勧めします。