2011-10-20 14 views
1

私はちょうど物を嘲笑に慣れています。このクラスではRhino Mockを使って私的なオブジェクトを模擬してください

private CoreDataContext _coreDataManager; 

:私はここで、このプライベート変数を持って

public class RatesControlReport 
     : Chatham.Panda.Batch.ProcessDefinition.BatchProcess 

このクラスは、私がCheckSwaptionVols(DateTime runDate)と呼ばれるテストすることにvoid方法があります。

私のテストの最初の部分で私はメインクラスインスタンス化することができます

RatesControlReport ratesControlReportProcess; 
      ratesControlReportProcess = new RatesControlReport(); 

を基本的に私はこの呼び出しを作りたい:

ratesControlReportProcess.CheckSwaptionVols(DateTime.Now); 

しかし、この方法ではそうのようなプライベート変数を使用しています:

System.Data.Linq.ISingleResult<CheckSwaptionVols> swaptionStatusResult = _coreDataManager.CheckSwaptionVols(this._runDate); 

私はこの変数の模擬バージョンを代わりに渡すことができたいと思います自分の指定したSystem.Data.Linq.ISingleResult<CheckSwaptionVols>を指定して、DBに依存せずにテストを続けることができます。

どうすればよいですか?

答えて

5

まあ、それはあなたのCoreDataContextのインスタンス化に依存します。これが静的コンテキストまたはコンストラクタで構築されている場合、実際にはそのためのモックを作成する方法はありません。このため、オブジェクト内の依存関係をインスタンス化することは一般的に悪い習慣とみなされます。あなたがする必要があるのは、依存性注入のいくつかの方法を提供することです。あなたが必死なら

public RatesControlReport(CoreDataContext context) 
{ 
    _coreDataManager = context; 
} 

...あるいは内部方法:これは、オーバーロードされたコンストラクタのような単純なことができ

internal void InjectContext(CoreDataContext context) 
{ 
    _coreDataManager = context; 
} 

一般しかし、それはへのベストプラクティスであると考えられ、話します常にはRatesControlReportを構築するときにCodeDataContextオブジェクトを提供します。これにより、ビジネスロジックからのデータアクセスが分離され、両方のクラスをより効果的に単体テストできるようになります。

+0

+1オブジェクトをコンストラクタに渡さないと、単体テストの設定が非常に「痛い」という結果になります。あるいは、単体テストをあきらめるのが面倒すぎるので、単体テストをあきらめてください。 –

関連する問題