17

ユニットテストを書くときは、RhinoMocksを使用するのが好きです。

そのため、最初のWindows Storeアプリケーションを起動したとき、当然、最初に単体テストを開始しました。NuGetを介してRhinoMocksを追加しようとすると、次のエラーが発生しました

パッケージ「RhinoMocks3.6.1」をインストールできませんでした。このパッケージを「.NETCore、Version = v4.5」を対象とするプロジェクトにインストールしようとしていますが、パッケージには、そのフレームワークと互換性のあるアセンブリ参照が含まれていません。詳細については、パッケージの作成者にお問い合わせください。

私はMoqでも同じ問題を抱えていました。

.NETCor、Version = v4.5のモックフレームワークはありますか？

4

5 に答える 5

15

ほとんどのモックフレームワークはに基づいていReflection.Emitます。残念ながらReflection.Emit、WinRTには含まれていません。これは、動的プロキシを実行できないことを意味します。（つまり、実行時のモック）。これにより、コンパイル時に参照されるモックの事前生成が残ります。私が知っている唯一のフレームワークは、Moqの実験的なブランチです：https ：//github.com/mbrit/moqrt

于 2012-08-25T03:54:55.760 に答える
2

これはWindowsPhone7で使用するために作成したもので、ビルド後の手順であるため、Win8でも機能するはずです。

http://dontcodetired.com/blog/post/Introducing-%28probably%29-The-Worlds-Only-Mocking-Framework-for-Windows-Phone-7-%28WP7%29.aspx

于 2013-04-24T08:56:21.033 に答える
1

これが私の提案です。私はまだこれらのどれもテストしていないことに注意してください。 これは、最初の2つのオプションについて説明している記事へのリンクです。

  1. TypeMock Isolator-高価ですが、それでうまくいくように見えます
  2. Microsoft Fakes（MSRのMolesというプロジェクトから発展）
  3. 嘲笑する（または依存性注入を行う）代わりに、別の手法を使用できます。パラメータ化されたインジェクションを使用して、テストする必要のある情報を渡すことができます。これにより、デリゲートやプリミティブへの大きなオブジェクトになり、モックフレームワークの必要性が軽減されます。実際のテクニックの例を含め、これについて詳しく説明します。
于 2012-08-27T00:26:28.143 に答える
0

実際、 FakeItEasyの寄稿者の1人であるPhilipp Dolderは、ポータブルクラスライブラリに基づいた、興味深く実用的なアプローチを考案しました。 http://www.planetgeek.ch/2013/02/01/fakeiteasy-and-windows-store-apps-are-becoming-friends/

本質的に、彼は次の解決策を提案します。

  1. TDDされるすべての生産的なコードをPCLクラスライブラリに入れ、サポートしたいターゲットフレームワークを選択します。
  2. テストアセンブリを通常のクラスライブラリとして作成します
  3. FakeItEasyおよび選択したテストフレームワーク（NUnit + FluentAssertionsなど）への参照を*.Testアセンブリに追加します
  4. テストできないUIコンテンツのみをWindowsストアアプリプロジェクトに配置します
于 2013-02-01T09:57:29.767 に答える
-1

元の質問は古いことは知っていますが、WindowsStoreAppsでモックを作成しようとしている人はまだたくさんいます。

私は最近、次のように述べているMoqaLateの使用を開始しました。WindowsPhoneおよびWindowsStoreアプリのモッキング。ソリューションを構築した後、実際にはMockingClassesを物理的に作成します。したがって、ビルド後、クラスのモック実装を含むフォルダーが作成されます。

私は最善の選択肢ではないと思います。実行時のモックは理想的ですが、その間に私のためにモックを作成します。

于 2015-07-30T13:28:52.637 に答える