2
私はTDDのワークフローに慣れていて、MVCとasp.net Web Formsアプリケーションが混在しています。WebFormsとMVCの両方を実行できるベストモックフレームワークですか？
MVCにはMOQをお勧めします。
私はRhino for Webフォームを使用しました。
誰にも、両方のフレームワークモックを1つ持つためのベストプラクティスはありますか？
A
答えて
1
Rhinoの最新リリースには、MoQの持つ甘い甘い3.5愛の多くが含まれています。私はMoQのファンだから、それは私が使っているものだ。しかし、MoQがやっていないことを行う場合に備えて、Rhinoも持っています。
TL; DR：MoQ it baby。
0
私は先に進み、両方のために私のお気に入りのフレームワークを使用します。 WebフォームとMVCのフレームワークを選択する理由はないと思います。はるかに大きな問題は、HttpRequestスタックの残りの部分からページを分離することは悪名高く難しいので、私はどのように私のWebフォームページをテストするのかということです。
私のお気に入りはMoqです。私はTypeMockも使用しました。それはお金を要しますが、それは本当に強力です。具体的なクラスとコンストラクタをモックすることができるので、HttpContextやHttpRequestのようなものを模倣する可能性があります。
1
TypeMockは非常に強力です。私がにユニットテストにが必要な場合、テスト容易性のために設計されていないWebフォームアプリが、私の人生を救った。
しかし、私はアーキテクチャパターン（MVC）を選ぶか、モックアビリティを可能にする設計をしています。それはとても使いやすく、他の人にも簡単に教えることができます。
TypeMockのレコード再生シンタックスはまだ私を混乱させますが、タイトなリリーススケジュールで時間を節約できました。 MoqのAPIはほぼ自明であり、模擬図書館の歴史を考えると素晴らしい成果です。
2
これは愚かな質問ですが、私はmocks vs. stubsをより完全に理解しているので、Rhino Mocksが好きです。
価格にコミットする前に、TypeMockを深く見てください。
また、ASP.NET MVCに推奨されるモックフレームワークはありません。
最後に、私はあなたのプロジェクト（そしてあなたのチームでさえ）の1つの模擬フレームワークに固執することをお勧めします - その違いは、巨大ではないものの、このような "研磨岩"決定。それは私が決定が長いものであってはならないことを意味し、何がうまくいくかを選び、価値を創造することで成し遂げます。
0
HTTPContextと従来のWebフォームを偽装するためのIvonnaを調べてください。