3

以下は、私の興味を引いた同僚が実際に提示した状況です。

public DoSomething()
{
    //Do Stuff
    var assembly = Assembly.LoadFrom("Path");
    //Do More Stuff
}

したがって、これをモックするには、2 つのオプションがあります。

internal virtualメソッドを作成します。

internal virtual IAssembly LoadAssembly(String path){...Load Here...}

または、渡すことができる新しいクラスを追加します

public class AssemblyLoader
{
    public virtual IAssembly LoadAssembly(String path){...Load here...}
}

最初のオプションはプライベート メソッドである必要があり、2 番目のオプションは単純な静的呼び出しのラッパーを作成する過剰設計であるように思われるため、両方のオプションが問題のようです。

それで、コミュニティに持っていこうと思いました。単体テスト可能でありながら、最も実用的なアプローチを探しています。

これは、この SO の質問に似ていますが、本当に深く掘り下げたいと思います。

4

2 に答える 2

3

質問が一般的すぎて、答えにくいです。

一般的に言えば、あなたの問題は人為的なものだと思います。サード パーティ サービスのラッパーを作成することは過剰設計であると主張しますが、同時に、このラッパーは実際の問題に対する解決策であると述べています。それが実際の問題を解決する場合、それは過剰設計のようには聞こえませんが、ラッパーは実際には優れた設計のように聞こえます。

サード パーティ サービスのラッパーを作成することは、自分が制御していないコードの状態を構成する必要がある場合に賢明です。思ったより臭くないです。実際、これを行う別の方法はありません。どのようにスライスしても、サード パーティのライブラリでモックを作成する場合でも、リフレクション マジックを使用する場合でも、目的のソリューションを使用する場合でも、最終的には実際のサード パーティの API をラップすることになります。

この外部 API をラップするのは過剰設計であると直感的に言う場合は、質問の構成を変更する必要があるかもしれません。このコードをテストする必要があるかどうかを自問してください。

于 2013-03-28T16:12:59.937 に答える
0

ここで一般化するのは難しいですが、アセンブリをロードする前後のコメントは、メソッドが単一責任DoSomethingの原則に違反している可能性があることを示唆しています。つまり、コードはあまりにも多くのことを行います。これを回避するようにコードを記述する方法はいくつかありますが、質問でそのうちの2つに言及しています。私はグレッグのアドバイスに従い、ここで依存性注入を実装すると思います。この例に基づいて、何がオーバーデザインで何がオーバーデザインでないかを言うのは難しいです。

于 2013-03-28T02:02:10.647 に答える