0

私のASP.NETMVC3（新規）開発では、MvcContrib TestHelper（したがって、Rhino Mocks）に依存関係を作成したくありません。ただし、それが大きな価値を提供している場合を除きます。だから私はこのヘルパーの現在の状況を理解しようとしています。

ドキュメントには、TestHelperが次のコントローラー依存関係の偽物を生成すると記載されています。

  • HttpContext
  • HttpRequest
  • HttpResponse
  • HttpSession
  • 形
  • TempData
  • クエリ文字列
  • ApplicationPath
  • PathInfo

MVC1とMVC2の場合、これがなぜそれほど役に立ったのかがわかります。しかし、MVC3は、TestHelperの適切性を低下させた可能性のある、改善されたテスト「シーム」の導入を開始しました。たとえば、MVC3RequestとResponseコントローラーのプロパティは、HttpRequestとHttpResponseの分離可能/注入可能なバージョンになるように特別に設計されています。

私はまだMVC3での妥当性の進歩を調査しているので、MVC3で改善された分離（または注入可能性）を受けた上記の他の依存関係の数を知りたいです。また、TestHelperを使用して、上記の依存関係の有無にかかわらず、偽物（スタブ/モック）を使用してテストを作成するMVC3でどのように見えるかを示すコードのサンプルを見てみたいと思います。

TestHelperを使用した場合と使用しない場合のテスト作成の違いが十分に小さい場合は、TestHelperを使用しないことをお勧めします。つまり、好きな分離フレームワーク（MOQまたはNSubstitute）を自由に選択できます。

最終的に、MVC3リリースがHttpRequestとHttpResponseに対して特定の改善されたテスト容易性手順を実行したが、上記の他の依存関係の問題に対しては実行しなかったことを知って驚かれることでしょう。TestHelperを使用せずに、誰かが上記のアイテムをどのように分離するかについての内訳を教えてくれることを願っています。

4

1 に答える 1

1

しかし、MVC3は、TestHelperの適切性を低下させた可能性のある、改善されたテスト「シーム」の導入を開始しました。たとえば、MVC3のRequestおよびResponseコントローラーのプロパティは、HttpRequestおよびHttpResponseの分離可能/注入可能なバージョンになるように特別に設計されています。

MVCは、ユニットのテスト可能性に関して、質問にリストしたオブジェクトに関してまったく新しいものを導入しませんでした。これらはASP.NETMVC1および2の抽象化であり、ASP.NET MVC 3の抽象化です。これにより、コントローラーのアクションとそれらに依存するコードを単独で単体テストできます。しかし、それを行うには、それらの依存関係をモックする必要があります。そこで、モックフレームワークが登場します。Rhino Mocksは、考えられるフレームワークの1つにすぎません。MVCContrib.TestHelperは、単体テストコントローラーアクションに非常に優れた流暢な構文を提供します。個人的にはいつも使っています。それは本当にユニットテストをより読みやすくし、あらゆる種類の配管、モック、インフラストラクチャコードでそれらを乱雑にすることを回避します。

たとえば、次の単体テストを確認してください：https ://github.com/darind/samplemvc/blob/master/tests/SampleMvc.Web.Tests/Controllers/UsersControllerTests.cs

ASP.NET MVC 3では、依存性リゾルバーとプロバイダーが導入されました。これにより、単純なコントローラー以外のフレームワークの他の多くの部分に依存性を注入できるため、以前は困難だった部分を単体テストできます。たとえば、アクションフィルター。

しかし、実際の単体テストに関しては、何も変わりません。

  1. テスト対象が依存し、単体テストで制御できるオブジェクトを表すモックを作成します
  2. モックオブジェクトに対する期待を定義します
  3. テストしている実際のメソッドを呼び出します
  4. あなたは結果を主張します
于 2012-04-13T17:45:40.780 に答える