問題タブ [automocking]

MOQ ライブラリに何も追加せずに、MOQ でコンテナーを自動モックすることが可能かどうか疑問に思います。IList を自動モックするクリーンな方法を見つけるのに問題があります。

前もって感謝します！

次のようなコントローラークラスがあるとします。

}

テスト ハーネスの場合:

Machine.Fakes がこのメソッドを自動モック化したために Subject.ResourceParent() が null を返すため、この単体テストは失敗します。一時的な回避策として、コードをテストできるように、ResourceParent から virtual キーワードを削除しました。Machine.Fakes にオーバーライドしないように指示するには、実際の解決策が必要だと思いますResourceParent()

AutoMockingで遊んでいます。

moq.contrib.indyを使用しているときに、コントローラーを呼び出すと次のエラーが発生します

{"値をnullにすることはできません。\r\ nパラメータ名：controllerContext"}

通常はこれを行います

AutoMockingを使用してこのためのコントローラーコンテキストをモックするにはどうすればよいですか？

Rhino Mockに実行時に「Expect.Calls」を自動的に生成させる方法はありますか？

したがって、Rhinoのモックを擬人化すると、次のようになります...「この設定に従って、これらのインターフェイスのいずれかを実装するクラスに属する、遭遇したメソッドのexpect.callを生成します。」

タイトルが示すように、コンストラクターも取る具象クラスを実装するインターフェイスを解決しようとしています。

例として、具体的なサービス クラスを次に示します。

ご覧のとおり、このサービス クラスには、コンストラクターのパラメーターとしてインターフェイスも必要です。MVC コントローラーのコンストラクターは次のようになります。

Unity.Mvc3 のおかげで Bootstrapper のインターフェイスを解決しました

したがって、私が抱えている主な問題は、UnityAutoMoq を使用した単体テスト内で、IMessageGenerator インターフェイスのモック化されたインスタンスを IMessageService に渡す方法です。私はこのようなものがうまくいくと思いますが、そうではありません:

私はmoqを使い始めましたが、私の理解から、実際にそれらを気にしなくても、呼び出すことができるすべてのメソッドを常にモックアップする必要があります。

やりたいことを忘れてしまうようなものをモックアップするのに時間がかかることがあります。だから私は自動モッキングを見ていましたが、何を使うべきかわかりません。

自動モッキングコンテナとしてのAutoFixture

オートモッキング

最初のものの使い方がまったくわかりません。私は2番目のものを手に入れましたが、実際に試したことはありません。

どちらかがもう一方より優れているかどうかはわかりません。私が知っている唯一のことは、最初のものの依存関係であるAutoFixturesをすでに使用しているということです。

したがって、長期的には最初のものを使用するのは理にかなっていますが、私が言ったように、それを使用する方法に関する基本的なチュートリアルは見つかりません。

編集

「NikosBaxevanis」の例に従おうとしていますが、エラーが発生しています。

私のpetapocounitOfWorkプロパティのせいだと思います

どういうわけかこれをモックアップしたのかどうかわからない。

本質的に、cmake のターゲットの一部ではないヘッダー ファイルをモックできるようにしたいのですが、それらのヘッダーのファイル名がわからないという追加の困難があります。

実際のプロジェクトは非常に複雑で、自動ビルド システムの一部です。以下は簡単な例です。次のような構造のプロジェクトを考えてみましょう。

CMakeLists.txt
src/lib/ source.cpp src
/lib/CMakeLists.txt
src/include/some_header.hpp # source.cpp に含まれる


メインの CMakeLists.txt の内容:

src/lib/CMakeLists.txt の内容:

source.cpp 内には、ファイル some_header.hpp が次のように含まれています。

問題:
ファイル some_header.hpp には Q_OBJECT が含まれており、いくつかのシグナルが含まれているため、moc はその魔法を働かせる必要があります。ただし、ヘッダーは実際のプロジェクト内にないため、ヘッダーはモックされません。some_header.hpp のファイル名さえ知らないので、具体的にモックするために追加することはできません。明らかに、AUTOMOC は、ソース ファイルにそれらのいずれかが含まれている場合でも、モック可能なファイルの include_directories をチェックしません。

私が試したこと（失敗）：

• 
  cmake のドキュメントで説明されているように、source.cpp で #include moc_some_header.cpp を使用します。これにより、cmake が some_header{.h,.hpp,.hxx,.H} を見つけられなかったというエラーが発生します。
• CMAKE_AUTOMOC_RELAXED_MODE を true に設定します。これが実際に何をするのかはドキュメントからは明らかではありませんが。とにかく違いはありませんでした。
• AUTOMOC_MOC_OPTIONS を -Isrc/include または -I/path/to/project/src/include または -I${CMAKE_HOME_DIRECTORY}/src/include に設定
  しても、何も表示されません。

AUTOMOC の素晴らしい点は、実際にどのファイルをモックする必要があるかを知る必要がないことです。ただし、この場合、ソース ファイルに含まれる、内部に Q_OBJECT が含まれている可能性のあるすべてのヘッダーを知る必要があります。

モック可能なファイルを探す場所をAUTOMOCに正確に伝える方法はありますか?

解決策が見つかったので、簡単に説明します。

AutoFixtureは、モックを正常にフリーズして返します。AutoFixtureによって生成された私のsutには、テストにとって重要なローカルデフォルトのパブリックプロパティがあり、AutoFixtureが新しい値に設定されていました。マークの答えからそれを超えて学ぶことがたくさんあります。

元の質問：

私は昨日、MoqがいたるところにあるxUnit.netテストでAutoFixtureを試し始めました。Moqのものの一部を置き換えたり、読みやすくしたりしたいと思っていました。特に、SUTFactoryの容量でAutoFixtureを使用することに興味があります。

AutoMockingに関するMarkSeemannのブログ投稿をいくつか用意して、そこから作業を試みましたが、それほど遠くはありませんでした。

AutoFixtureを使用しない場合のテストは次のようになります。

ここでの話は十分に単純です-正しいキー（ハードコードされている/プロパティが挿入されている）で依存関係をSettingMappingXmlクエリしISettings、結果をとして返すことを確認してXElementください。エラーがあるITracingService場合にのみ関連します。

私がやろうとしていたのは、ITracingServiceオブジェクトを明示的に作成してから手動で依存関係を挿入する必要をなくすことです（このテストが複雑すぎるためではなく、試して理解するのに十分簡単だからです）。

AutoFixtureを入力してください-最初の試み：

CreateAnonymous<SettingMappingXml>()コンストラクターパラメーターが検出されると、そのインターフェイスに具体的なインスタンスが登録されていることに気づき、それを注入することを期待ISettingsしますが、それは行わず、代わりに新しい匿名の実装を作成します。

fixture.CreateAnonymous<ISettings>()実際に私のインスタンスを返すので、これは特に混乱します-

テストを完全にグリーンにします。この行は、インスタンス化するときにAutoFixtureが内部で実行することを期待していたものとまったく同じSettingMappingXmlです。

次に、コンポーネントをフリーズするという概念があるので、モックオブジェクトを取得するのではなく、フィクスチャ内のモックをフリーズするだけで済みます。

確かに、これは完全に正常に機能します-SettingMappingXmlコンストラクターを明示的に呼び出し、に依存しない限りCreateAnonymous()。

簡単に言えば、それが私が思いつくことができるどんな論理にも反するので、なぜそれが明らかにそれがするように働くのか理解していません。通常、私はライブラリのバグを疑うでしょうが、これは非常に基本的なものであるため、他の人がこれに遭遇し、長い間発見されて修正されていたと確信しています。さらに、テストとDIに対するMarkの熱心なアプローチを知っているので、これは意図的ではありません。

つまり、私はかなり初歩的な何かを見逃しているに違いありません。事前設定されたモックオブジェクトを依存関係としてAutoFixtureでSUTを作成するにはどうすればよいですか？私が今確信している唯一のことは、私が必要としているので、のAutoMoqCustomizationために何も設定する必要がないということですITracingService。

AutoFixture / AutoMoqパッケージは2.14.1、Moqは3.1.416.3で、すべてNuGetからのものです。.NETバージョンは4.5（VS2012とともにインストール）であり、動作はVS2012と2010で同じです。

この投稿を書いているときに、Moq 4.0とアセンブリバインディングリダイレクトに問題があることがわかったので、Moq 4のすべてのインスタンスのソリューションを細心の注意を払ってパージし、AutoFixture.AutoMoqを「クリーンな」プロジェクトにインストールしてMoq3.1をインストールしました。ただし、私のテストの動作は変更されていません。

ポインタや説明をありがとうございます。

更新： Markが要求したコンストラクターコードは次のとおりです。

完全を期すために、GetXml()メソッドは次のようになります。

SettingKey単なる自動プロパティです。

私は最近、依存関係がかなり大きくなり始めたプロジェクトに取り組んでおり、AutoMockingコンテナーを使用してテストを少しクリーンアップし、脆弱性を減らすというアイデアを模索しています。

TDD / BDDの純粋主義者がそれらを使用することに反対する議論を聞いたことがあります。たとえば、テスト対象にどの依存関係が必要かはすぐにはわかりません。または、本当に必要のない依存関係を追加できます。どちらも、それらを使用することに反対する特に強い議論のようには聞こえません。

私の見解では、1つを導入すると、必要に応じてリファクタリングし、ビジネス要件に沿って依存関係を削除して導入できます。コードをコンパイルするためだけにテストに戻って新しいモック/スタブを導入する必要はありません。

AutoMockingは良い/悪い習慣であると考えられていますか？使用すべきまたは使用すべきでない特定の状況はありますか？

AutoMoqでAutoFixtureを使用しています。ゲッターはあるがセッターはないプロパティを持つクラスの偽のインスタンスを作成しようとしています。AutoFixtureがモックを構成して、セッターがなくても指定された値を返すようにすることを期待しています。

私のコードはそのようなものです：

残念ながら、この場合、「With」メソッドは機能しません。これは、自動フィクスチャがデータにセッターがないと言っているため、後でモックを直接呼び出して値を設定する必要があるためです。

自動フィクスチャがそれ自体でこれを実行できる方法はありますか？コードの最後の行は必要ありませんか？

編集：私は間違いを犯しました、コード例は機能しません。そのはず

それでも、偽のインスタンス用のwithメソッドがあればよいでしょう。