コンポジションルートにユニットテストが必要ですか？

Question

私は答えを見つけようとしていましたが、直接議論されていないようです。 DIコンテナを作成してそこにすべて登録し、すべての依存関係を取得する必要なトップレベルクラスを解決するアプリケーションのコンポジションルートがあります。これはすべて内部的に起こっているため、構成ルートを単体テストすることは難しくなります。あなたは仮想メソッドや保護されたフィールドなどを行うことができますが、私は単体テストにできるように、そのようなものを導入することについて大きなファンではありません。コンストラクタインジェクションを使うので、他のクラスに大きな問題はありません。だから質問は - それは構成ルートを全くテストするのが大変意味がありますか？それにはいくつかの追加ロジックがありますが、それほど多くはありません。ほとんどの場合、アプリケーションの起動中にポップアップが発生します。私が持っている いくつかのコード：

public void Initialize(/*Some configuration parameters here*/) 
    { 
     m_Container = new UnityContainer(); 

     /*Regestering dependencies*/ 

     m_Distributor = m_Container.Resolve<ISimpleFeedMessageDistributor>(); 
    } 

    public void Start() 
    { 
     if (m_Distributor == null) 
     { 
      throw new ApplicationException("Initialize should be called before start"); 
     } 

     m_Distributor.Start(); 
    } 

    public void Close() 
    { 
     if (m_Distributor != null) 
     { 
      m_Distributor.Close(); 
     } 
    } 

Answer 1

それがすべてで構図のルートをテストするために、あまり意味がありませんか？

、あなたのアプリケーションが正しく書かれているかどうかを知りたいですか？おそらくそうしているので、テストを書くのです。同じ理由から、コンポジションルートをテストする必要があります。

しかしながら、これらの試験は、特に、システムの配線の正確に標的化されます。 1つのクラスが正しく機能するかどうかは、すでに何らかの単体テストでカバーされているので、テストしたくありません。クラスが他のクラスを正しい順序で呼び出すかどうかをテストする必要もありません。これは、通常の統合テストでテストしたいものです（MVCコントローラを呼び出して、呼び出しがデータベースで終了するかどうかをそのような統合テスト）。すべてのトップレベルクラスを解決できること

• ：

  ここでは、おそらくテストする必要がありますいくつかのものです。これにより、アプリケーションのすべての画面をクリックして、すべてが正しく配線されているかどうかを調べることができなくなります。

• これらのコンポーネントは、同等またはより長い存続期間のサービスにのみ依存します。コンポーネントがより短い寿命で構成された別のコンポーネントに依存する場合、そのコンポーネントはその依存関係の存続期間を「促進」し、再現や修正が難しいバグに繋がります。この種の問題を確認することが重要です。このタイプのエラーは、ライフスタイルの不一致または非依存性としても知られています。
• アプリケーションの正確さのために重要であるデコレータおよび他のインターセプションメカニズムが正しく適用されていること。デコレータは、トランザクション処理、セキュリティ、キャッシングなどのクロスカッティングに関する懸念を追加することができます。これらの懸案事項を正しい順序で実行することが重要です（キャッシュを照会する前にセキュリティチェックを実行する必要があります）。通常の統合テストを使用してこれをテストします。

これを行うには、verifiable DI configurationが必要です。

は、しかしそのnot everybody共有この意見に注意してください。しかし私の経験では、設定の正確性を確認することは非常に貴重です。

他のIoCコンテナは、これであなたを助けるための設備を持っている（ただし、Unityが、残念ながら、これらの機能のほとんどが欠けている）しながら、だから、これらのものは、いくつかのIoCコンテナに挑戦することができますテスト。

一部のコンテナでも設定を確認することを呼び出すことができる検証方法のいくつかの並べ替えを持っています。どのような「検証」手段が各ライブラリごとに異なるか。シンプルインジェクター（Simple Injectorのリードデベロッパー）はVerifyメソッドを使用してすべての登録を繰り返し、すべてのインスタンスを確実に作成できるようにそれぞれにGetInstanceを呼び出します。可能であれば、私はいつもコンポジションルートにVerifyと呼んでいるアドバイスをしています。設定が大きくなると、Verifyを呼び出すとアプリケーションの起動が遅くなる可能性があるため、これは必ずしも可能ではありません。しかしそれでも、それは良い出発点であり、多くの痛みを取り除くことができます。時間がかかる場合は、いつでも自動テストにコールを移動できます。

シンプルインジェクタの場合、これはほんの始まりに過ぎません。 Simple Injectorには、先に述べた「ライフスタイルの不一致」など、一般的な設定ミスでコンテナをチェックするDiagnostic Servicesが含まれています。

あなたは絶対にテストしたいと思いますが、これらのテストを単独で（データベースやWebサービスにヒットする必要なしに）実行することはできますが、これらのテストを「ユニットテスト」と呼ぶかどうかはわかりません。