フィルター属性プロパティの挿入は、スタンドアロン機能として利用できるものとしてではなく、MVC/ASP.NET パイプラインの一部として機能します。
おそらく、MVC コントローラーのフィルターは単体テスト中にも実際には実行されないことに気付くでしょう。たとえば、コントローラー アクションに HandleErrorAttribute を配置し、単体テストでそのアクションから例外をスローします。エラー ビューに移動しようとして、HandleErrorAttribute が呼び出されなかったことに注意してください。
これは、単体テストのシナリオでは、MVC パイプラインにいないためです。コントローラー/アクションを POCO (Plain Old CLR Objects) としてテストしています。モデル バインディング、フィルター、HttpModules、または実際の統合/実行の一部として通常見られるその他のものは取得されません。
これはエラーではなく、仕様です。これは、WCF サービスの実装を単体テストする方法と似ており、web.config を介してそれらに動作をアタッチすると、単体テストでそれらの動作が表示されなくなります。単体テストはパイプラインで実行されていません。スタンドアロン エンティティとして 1 つのクラスに対してのみ実行されています。
全体がフィルターなどとどのように連携するかをテストする必要がある場合 (統合テスト)、ブラウザーの自動化またはその他のプログラムによる Web クライアント メカニズムを使用して、実行中の Web アプリケーションのバージョンからコンテンツを取得する方法を検討する必要があります。パイプラインを配置するには、標準/スタンドアロンの単体テスト環境ではなく、実際の完全なランタイムで実際に実行する必要があります。
単体テストで DI を使用してもよいかどうかは、個人的な好みです。一部のテストで使用していますが、使用する場合は、依存関係としてモック/スタブを接続して、テスト対象のシステムとその依存関係の間の相互作用を制御できるようにします。そのためにDIは必要ありません。すべての偽の依存関係を手動で構築し、DI/IoC コンテナーをまったく使用せずにそれらを突っ込むことができます。つまり、単体テスト環境では、クラスを単体としてテストしていないため、The Real Dependencies を配線するべきではありません。これは統合テストです。