3

タイプBarのプライベートメンバーを持つクラスFooがあるとします。Fooの実装にBarが含まれていることをユーザーに知られたくないし、ユーザーが独自のBarを作成して、Fooのコンストラクター、その他のメソッド、または構成ファイルに渡すことができないようにする必要があります。

編集：バーは、特別なデータベース、ネットワーク接続、または別のプロセスなど、テスト環境の制御外のリソースにアクセスするという点でも問題があります。

Fooの単体テストもできるようにしたい場合はどうしますか？依存性注入はまだ可能ですか？これは、BarとFooが緊密に結合されていることを意味し（依存関係が一方向である場合でも）、この状況が受け入れられる状況になることは決してありませんか？

4

4 に答える 4

5

あなたがそれを助けることができれば、あなたは依存関係を隠したくありません。

コードの場合はBar、高価なリソースに直接アクセスするのではなく、高価なリソースによって生成されたオブジェクトを受け入れるように再設計して、依存関係を明示的にする必要があります。データベースアクセスコード（またはそれが何であれ）を、インジェクトでき​​る場所に移動しBarますFoo。テストは2倍になります。

それが実用的でない場合（つまり、他の誰かのクラスを扱っている場合）、Drorのリストは非常に優れています。

于 2010-02-15T16:45:03.223 に答える
4

[免責事項：私はTypemockで働いています]

3つの選択肢があります。

  1. Barクラスを設定する内部メソッドを作成します-assemblyInf.csファイルのInternalVisibleToを使用して、テストでそのクラスを設定できるようにします。
  2. DIを使用してBarクラスを注入し、テスト中にそのクラスをダミーまたは偽物に変更します。
  3. Typemock Isolator（.NET）のようなFaking / Mockingフレームワークを使用して、を使用して別のクラス内で作成されたオブジェクトに偽の動作を設定できるようにします。Isolate.Swap.NextInstance<Bar>.With(fakeBar);
于 2010-02-15T16:23:19.057 に答える
1

バータイプがFooの実装の詳細にすぎない場合、単体テストでは、とにかくFooのパブリックインターフェイスのみを実行する必要があるため、バーの作成について心配する必要はありません。

編集：Barが外部リソースにアクセスする場合、Fooの明示的な依存関係にし、インスタンスをFooのコンストラクターに渡して、単体テスト用に簡単にモックできるようにする必要があります。

于 2010-02-15T16:22:04.670 に答える
1

あなたの問題はあなたがプライベートメンバーにアクセスする必要があるということではありません。これは、問題のクラスが分離されるように設計されていないという事実の症状にすぎません。非常に特殊な使用法を1つだけ許可newします。それは、高価なリソースに移動するオブジェクトをアップすることです。

テスト不可能な設計をハッキングすることに成功したとしても、統合テストのみを実行することになります。単体テストは分離に関するものであり、統合の反対です。そのクラスは分離できないため、定義上、単体テストすることはできません。

依存関係を外部化することが望ましくない理由はありますか？このオブジェクトは、他のオブジェクトと同様に依存関係が注入されることを免除されますか？

編集：

もちろん、いくつかのトリックでそれを分離できることを私は理解しています。ただし、これらの手法はパブリックインターフェイスをバイパスし、将来の柔軟性を制限し、誰かがそれを壊す可能性を高めます（基本的に、プライベートメンバーの有用性を無効にします）。

于 2010-02-15T22:34:07.270 に答える