問題タブ [mocking]

私は RhinoMocks でいくつかのモックを作成してきましたが、モックされたメソッドを仮想化する必要があります。現在仮想としてマークされていない、モックしたいメソッドを含むカスタムフレームワークがあることを除いて、これは問題ありません。

これらのメソッドを仮想化することによる問題は予測できませんが、メソッドを仮想化することの潜在的な危険性にはどのようなものがあるのでしょうか?

フェイク、スタブ、モック、動的モックの考え方に慣れてきました。しかし、部分モックをいつ使用するかについての理解には、まだ少し不安があります。

サービスのモックを計画していて、部分的なモックに頼る必要がある場合、それは設計が悪いことを示しているようです。部分的なモックは主にレガシー コードをテスト カバレッジの下に置くためのものなのでしょうか?

これとは逆に、Reset() メソッドを持つクラスをテストしているとします。別のテストで Reset() メソッドが機能することを既に確認しており、このメソッドの呼び出しで終了する必要があるクラスの機能がいくつかある場合、オブジェクトの部分的なモックを作成して実行するテスト設計は貧弱ですか? Reset() メソッドで Expectation を定義して、部分モックに対してテストします。

現在、この方法でいくつかのテストをセットアップしていますが、この種のことで後で問題が発生することはありますか?

私はリポジトリを書いています。オブジェクトのフェッチは、DAO を通じて行われます。オブジェクトの作成と更新は、RequestHandler オブジェクトに渡される Request オブジェクトを介して行われます (コマンド パターンのように)。DAO、Request、または RequestHandler を作成していないため、変更できません。

このリポジトリのテストを作成しようとしています。DAO と RequestHandler の両方をモックアウトしました。私の目標は、モックされた RequestHandler が、新しいオブジェクトまたは更新されたオブジェクトをモックされた DAO に単純に追加することです。これにより、DB と話しているような錯覚が生まれます。このように、このリポジトリを呼び出すすべてのクラスのリポジトリをモックする必要はありません。

問題は、Request オブジェクトが文字列の塊とさまざまな英数字コードの塊であることです。XMLも関係していると確信しています。それは一種の混乱です。別の開発者が、格納されているオブジェクトに基づいて Request オブジェクトを作成するコードを作成しています。また、RequestHandler は、保存しているオブジェクトではなくリクエストを受け取るため、モックされた DAO を更新できません。

問題は、リクエストもモックするか、それとも遅い人がコードを書き終えるまで待ってからテストを書くべきかということです。それとも、リポジトリを呼び出すクラスをテストするときに、それを台無しにしてリポジトリ全体をモックアウトしますか?

ところで、「モック」とは NMock の意味ではなく、メモリ内コレクションで DB を偽造するようなものです。

私は、バックエンドでさまざまな複雑さのデータベースによって駆動される多くの Web アプリケーションを扱っています。通常、ビジネスおよびプレゼンテーション ロジックとは別のORMレイヤーがあります。これにより、ビジネス ロジックの単体テストがかなり簡単になります。個別のモジュールに実装でき、テストに必要なデータはオブジェクトのモックによって偽造できます。

しかし、ORM とデータベース自体のテストには、常に問題と妥協が伴います。

何年にもわたって、私はいくつかの戦略を試してきましたが、完全に満足できるものはありませんでした.

• テスト データベースに既知のデータを読み込みます。ORM に対してテストを実行し、正しいデータが返されることを確認します。ここでの欠点は、テスト DB がアプリケーション データベースのスキーマ変更に対応する必要があり、同期が取れなくなる可能性があることです。また、人工データに依存しており、愚かなユーザー入力によって発生するバグを明らかにしない場合があります。最後に、テスト データベースが小さい場合、インデックスの欠落などの非効率性は明らかになりません。(OK、最後のテストは実際には単体テストを使用する目的ではありませんが、害はありません。)

• 本番データベースのコピーをロードし、それに対してテストします。ここでの問題は、いつでも実動 DB に何が入っているか分からない可能性があることです。時間の経過とともにデータが変更された場合、テストを書き直す必要がある場合があります。

これらの戦略はどちらも特定のデータに依存しており、単体テストでは機能のみをテストする必要があると指摘する人もいます。そのために、私は提案されたのを見てきました：

• モック データベース サーバーを使用し、特定のメソッド呼び出しに対して ORM が正しいクエリを送信していることのみを確認します。

データベース駆動型アプリケーションをテストするためにどのような戦略を使用しましたか? 何があなたにとって最も効果的でしたか?

人々は TcpClient (または TcpClient のようなもの) をモックアウトするためにどのようにアプローチしますか?

TcpClient を受け取るサービスがあります。それをもっとモック可能な何かでラップする必要がありますか？これにどのようにアプローチすればよいですか？

私はモックオブジェクトを初めて使用しますが、モックを作成するには、クラスにインターフェイスを実装させる必要があることを理解しています。

私が抱えている問題は、データアクセス層に静的メソッドが必要なのに、インターフェイスに静的メソッドを配置できないことです。

これを回避する最善の方法は何ですか？インスタンスメソッドを使用する必要がありますか（これは間違っているようです）、それとも別の解決策がありますか？

私は単にそれを機能させることができませんでした、そして私は自分の時間を無駄にしているのか、それとも単に愚かであるのか疑問に思っています！

申し訳ありませんが、現在の正確なエラーはありません。しかし、私はそれが機能するかどうかを知りたいだけです！

単体テストでこれらのオブジェクトを提供するためのより良いアプローチは何かを尋ねたいだけです。

私の単体テストでは、CSLAオブジェクトをテストしています。CSLAオブジェクトは、内部でApplicationUserオブジェクトの1つのプロパティと1つのメソッドを使用しています。ApplicationUserはIPrincipalから継承されます。プロパティは次のとおりです。1）ApplicationContext.User.IsInRole（...）-メソッドはIPrincipalの一部です2）ApplicationContext.User.Identity.Name-名前はApplicationUserの一部であるIIdentityのプロパティです別名IPricipal

私のテストの例（RhinoMockを使用）：

2番目の値であるID名に少し問題があります。私はそれをモックしようとしましたが、内部で行われるため、モックされたIIdentityをApplicationUserに割り当てるのに問題があります。IIPrincipal（IIdentityを含む）を自分で作成するだけで、モックを作成しないように言われました。これは確かに行うことができます。これを使用してスタブとして呼び出すことができるかどうかわかりませんか？

では、IPrincipalとIIdentityの扱い方を教えていただけますか？どんな提案でも大歓迎です。

私は自分のテストでjmockitを使用しており、テストしたい1つのクラスでInitialContext直接使用しています。だから私は次のものを持っています：

私のテストケースでは、これを呼び出して「モック」InitialContextクラスを使用します。

InitialContextjmockit でクラスをモックする最良の方法は何ですか。

私はすでにいくつかの方法を試しました（自分のを使用するなどMockInitialContextFactory）が、同じエラーに遭遇し続けています：

私が Google で見る限り、JNDI を使ったモックは非常に厄介です。誰かが私にガイダンスを提供したり、解決策を教えてくれませんか? それは大歓迎です。ありがとうございました。

ここでいくつかの回答を読みました：ビューとコントローラーのテスト、およびモックですが、セッション値（またはその他のコンテキストベースの変数）を読み取って設定するASP.NETMVCコントローラーをテストする方法を理解できません。テストメソッドに（セッション）コンテキストを提供するにはどうすればよいですか？答えをあざけるのですか？誰か例がありますか？基本的に、コントローラーメソッドを呼び出してコントローラーにそのセッションを使用させる前に、セッションを偽造したいと思います。何か案は？