2017-08-14 11 views
0

残念ですが、これはどのように動作するのか分かりませんので、共有するコードはあまりありません。テストプロジェクトからDryIocのコンクリート実装への依存関係を渡す方法

私はAPI.Testsというテストプロジェクトを持っています。私はAPIプロジェクト内でNewsControllerのテストを書いています。私はテストからAPIへの依存関係を一方向のリファレンスとしてどのように渡すのかよく分かりません。

NewsController

private IGetNews _getNews; 
    private IAddNews _addNews; 
    private ILoggingService _log; 

    public NewsController() 
    { 
     _getNews = RegisterDependencies.container.Resolve<IGetNews>(); 
     _addNews = RegisterDependencies.container.Resolve<IAddNews>(); 
     _log = RegisterDependencies.container.Resolve<ILoggingService>(); 
    } 

答えて

1

あなたの現在のコードはサービスロケータアンチパターンを使用しています。これにより、コントローラはこれらの依存関係に緊密に結合され、分離してテストすることが困難になります。これらの依存関係を逆転させる必要があります。 (つまり:依存関係の逆転)

コントローラがコンストラクタインジェクションを介して明示的な依存関係を使用するようにリファクタリングします。

public class NewsController { 
    private readonly IGetNews getNews; 
    private readonly IAddNews addNews; 
    private readonly ILoggingService log; 

    public NewsController(IGetNews getNews, IAddNews addNews, ILoggingService log) { 
     this.getNews = getNews; 
     this.addNews = addNews; 
     this.log = log; 
    } 

    //...other code 
} 

ユニットテストでは、被験者に依存関係を擬似的に注入して注入することができます。次の例では、依存関係を模擬し、あなたがテストケース/シナリオに合わせて、依存関係を設定しますテスト

public void ExampleNewsControllerTest() { 
    //Arrange 
    var getNews = Mock.Of<IGetNews>(); 
    var addNews = Mock.Of<IAddNews>(); 
    var log = Mock.Of<ILoggingService>(); 

    var subject = new NewsController(getNews, addNews, log); 

    //Act 
    //...exercise the method under test 
    subject.SomeAction(); 

    //Assert 
    //...assert that the subject behaves as expected. 

} 

下の対象にそれらを注入するモックフレームワーク(部品番号)を使用しています。

+0

はい、これを行う古典的なやり方です。私が使っていたものですが、テストの実装以来、APITestsプロジェクト内の別の登録依存関係を使用するために、APIプロジェクトでDryIoCにどのように伝えますか?具体的なクラスはAPI.Testsプロジェクトにありますか? 私は、モックされる必要のないモックを渡すことなく、単に「DryIoc」の代わりに「IGetNewsのこの実装を解決してください」と伝えることができます。 –

+0

これはWeb APIコントローラなので、空のコンストラクタを持つ必要があることにも言及しておきます。 –

+1

@ChristopherJohnson、Web APIコントローラは空のコンストラクタ**を持つ必要はありません。コントローラを初期化しようとしたときに発生するエラーに対して、フレームワークがスローするデフォルトの誤解を招くエラーメッセージです。フレームワークを読んでおく必要があります。また、既に判明しているように、デザインの選択肢が悪いためにテストするのが難しいという設計をレビューする必要があります。 DIパターンと呼んでいるのは、実際にはサービスロケータのanit-patternです。 – Nkosi

関連する問題