2

プロジェクトでは、MEF フレームワークの CompositeContainer クラスを使用しています。ここで、ComposeParts (AttributedModelServices の拡張メソッド) メソッドが呼び出されるかどうかを検証する単体テスト (moq を使用) を作成したいと思います。

メソッドは仮想ではないため、 moq でモックするだけでは機能しません。これを行ういくつかの方法を見つけましたが、それらのすべてで CompositeContainer クラスを変更する必要があり、これを行うことはできません。

外部のサードパーティ ライブラリの非仮想メソッドが呼び出されているかどうかを moq でテストする方法はありますか?

お返事ありがとうございます。

コード例:

public void Load(string path, CompositionContainer container)
{           
    container.ComposeParts(this);           
}

ここで、コンテナは MEF ライブラリからのもので、ComposeParts は System.ComponentModel.Composition 名前空間の拡張メソッドです。

//
// Summary:
//     Creates composable parts from an array of attributed objects and composes
//     them in the specified composition container.
//
// Parameters:
//   container:
//     The composition container to perform composition in.
//
//   attributedParts:
//     An array of attributed objects to compose.
public static void ComposeParts(this CompositionContainer container, params object[] attributedParts);
4

3 に答える 3

0

メソッドが呼び出されたことを確認するだけの場合は、同じメソッド シグネチャを持つ ICompositionContainer というラッパー インターフェイスで CompositionContainer をラップできます。次に、Moq を使用して、メソッドが呼び出されたことをアサートできます。

mock.Verify(cc => cc.ComposeParts(), Times.Once());

ここでの欠点は、元の実装が実装していないという事実を隠すためにインターフェイスを作成していることです。

サンプルコードは次のようになります。

public void Load(string path, ICompositionContainer container)
{           
    container.ComposeParts(this);           
}

SystemWrapperなど、.NET フレームワークでクラスをテストするために問題をラップする他のプロジェクトの例があります。

于 2013-08-06T20:01:23.663 に答える
0

あなたのクラスに実装された Load メソッドですか？そこから削除することを検討しましたか？単一責任の原則を考慮すると、あなたのクラスはやりすぎのようです。

機能を分割することをお勧めします。クラスは、必要なビジネスロジックをすべて実行します。そして、コンテナを構成する責任がある別の「インフラストラクチャ」クラスを用意します-あなたの場合、クラスのインスタンスを取得し、それをコンテナに登録します。

ほとんど同じ問題がありますが、別の場所にあります。そして、この「新しい」場所はその機能性に重点を置いており、実際のコンテナーを使用して分離してテストし、適切な部分が構成されているかどうかを調べることができます。

于 2013-08-06T13:57:39.677 に答える