0

問題

状況の絵を「描いて」みましょう。

  • 私はSUTを持っています。（持っているのは良いことです：P）
  • SUTにいくつかの依存関係を注入できます。
  • メソッドでは、次のことを行います：new OtherClass（ParametersObtainedFromDependancies）。
  • OtherClassが正しく機能するために意味のあるモックオブジェクトを作成する複雑さを処理せずに、SUTでそのメソッドを単体テストしたいと思います。これは、OtherClassをテストすることを意味します。

これに対する私の解決策は、デリゲートを使用するファクトリメソッドでした。

public Func<OtherClass,Param1Type> GetOtherClass = 
       (param1) => new OtherClass(param1);

悪い点：それは公開されています。必要に応じてオーバーライドできるオプションの依存関係と考えることができます。しかしとにかく、公衆はにおいがします。

良い点：このメソッドをオーバーライドするMyTestSUTを作成する必要はなく、SUTでモックを使用してそのメソッドをオーバーライドする必要もありません。

質問

より良い解決策はありますか？これは正しいです？

4

2 に答える 2

2

なぜパブリックフィールドにしたのですか？基本的には他の依存関係のように思えOtherClassます。他の値を指定したときに を提供するものが必要です。他の依存関係のようにコンストラクターパラメーターにしないのはなぜですか (または、依存関係の注入の残りを行っています)。

必要に応じて、このパラメーターを使用せずにコンストラクターのオーバーロードをいつでも提供できます。このパラメーターは、より長いパラメーターに委譲します。これが、私が通常「デフォルト」の依存関係の実装を提供する方法です。

別の言い方をすれば、IAuthenticatorこれは、ユーザー名とパスワードが提供されたときにUserProfile? インターフェイスの宣言を避けるためにデリゲートをショートカットとして使用している場合がありますが、それは単なる詳細な IMO です。時間が経つにつれて、実際には「提供」部分にもっとスマートなものを入れたいと思うかもしれません - 例えばキャッシング。

于 2011-12-03T12:41:39.747 に答える
0

AutoMoqカスタマイズが有効になっているAutoFixtureに似たものを使用したいようです。これにより、必要に応じて、SUT のパブリック フィールドのすべてまたは一部を、他のコンストラクター パラメーターと共にモックできます。

于 2011-12-03T12:45:05.463 に答える