依存関係の逆転によりAPIが拡張され、不要なテストが発生する

この質問は数日間私を悩ませてきました、そしてそれはいくつかの実践が互いに矛盾しているように感じます。

例

反復1

public class FooDao : IFooDao
{
    private IFooConnection fooConnection;
    private IBarConnection barConnection;

    public FooDao(IFooConnection fooConnection, IBarConnection barConnection)
    {
        this.fooConnection = fooConnection;
        this.barConnection = barConnection;
    }

    public Foo GetFoo(int id)
    {
        Foo foo = fooConection.get(id);
        Bar bar = barConnection.get(foo);
        foo.bar = bar;
        return foo;
    }
}

これをテストするとき、IFooConnectionとIBarConnectionを偽造し、FooDaoをインスタンス化するときに依存性注入（DI）を使用します。

機能を変更せずに実装を変更できます。

反復2

public class FooDao : IFooDao
{
    private IFooBuilder fooBuilder;

    public FooDao(IFooConnection fooConnection, IBarConnection barConnection)
    {
        this.fooBuilder = new FooBuilder(fooConnection, barConnection);
    }

    public Foo GetFoo(int id)
    {
        return fooBuilder.Build(id);
    }
}

さて、このビルダーは書きませんが、FooDaoが以前に行ったのと同じことを想像してください。これは単なるリファクタリングであるため、機能が変更されることはありません。そのため、私のテストはまだ成功しています。

IFooBuilderは、ライブラリで機能するためだけに存在するため、内部です。つまり、APIの一部ではありません。

唯一の問題は、依存関係の逆転に準拠しなくなったことです。この問題を修正するためにこれを書き直した場合、次のようになります。

反復3

public class FooDao : IFooDao
{
    private IFooBuilder fooBuilder;

    public FooDao(IFooBuilder fooBuilder)
    {
        this.fooBuilder = fooBuilder;
    }

    public Foo GetFoo(int id)
    {
        return fooBuilder.Build(id);
    }
}

これでうまくいくはずです。私はコンストラクタを変更したので、これをサポートするために（またはその逆に）テストを変更する必要がありますが、これは私の問題ではありません。

これをDIと連携させるには、FooBuilderとIFooBuilderをパブリックにする必要があります。これは、突然FooBuilderのライブラリのAPIの一部になったため、FooBuilderのテストを作成する必要があることを意味します。私の問題は、ライブラリのクライアントが、意図したAPI設計であるIFooDaoを介してのみ使用することであり、テストはクライアントとして機能します。依存関係の逆転に従わない場合、テストとAPIはよりクリーンになります。

言い換えれば、クライアントとして、またはテストとして私が気にしているのは、正しいFooを取得することであり、それを構築する方法ではありません。

ソリューション

• 私は単に気にしないでください、それはDIを喜ばせるためだけに公開されていますが、FooBuilderのテストを書いてください？-反復3をサポート

• APIの拡張は依存関係の逆転の欠点であることを理解し、ここで準拠しないことを選択した理由を明確にする必要がありますか？-反復2をサポート

• クリーンなAPIに重点を置いていますか？-反復3をサポート

編集：私は私の問題であることを、それを明確にしたいではない「？どのようにテストの内部に」ではなく、それはのようなもので、「私は内部のそれを維持し、まだDIPに準拠することができ、およびIばよいですか？」。

私は一緒に行きます：

APIの拡張は依存関係の逆転の欠点であることを理解し、ここで準拠しないことを選択した理由を明確にする必要がありますか？-反復2をサポート

ただし、オブジェクト指向とアジャイルデザインのSOLID原則（a 1:08:55）では、ボブおじさんは、依存関係注入に関する彼のルールはすべてを注入するのではなく、戦略的な場所にのみ注入することだと述べています。（彼はまた、依存関係の逆転と依存関係の注入のトピックは同じであると述べています）。

つまり、依存関係の逆転は、プログラム内のすべてのクラスの依存関係に適用されることを意図したものではありません。あなたは戦略的な場所でそれをするべきです（それが支払う（または支払うかもしれない）とき）。

私が見たさまざまなコードベースのいくつかの経験/観察を共有します。注：私は特にアプローチを推奨しているわけではありません。そのようなコードが実行されているのを目にしたところで共有するだけです。

私が気にしない場合は、DIを喜ばせるためだけに公開されていますが、FooBuilderのテストを記述します

DIおよび自動テストの前は、必要な範囲に何かを制限する必要があるという認識が受け入れられていました。ただし、最近では、テストを容易にするために内部に残すことができるメソッドを確認することも珍しくありません（これは通常、別のアセンブリで発生するため）。注意：内部メソッドを公開するディレクティブがありますが、これは多かれ少なかれ同じことです。

APIの拡張は依存関係の逆転の欠点であることを理解し、ここで準拠しないことを選択した理由を明確にする必要がありますか？

DIは間違いなく、追加のコードでオーバーヘッドが発生します。

クリーンなAPIに重点を置いていますか

DIフレームワークは追加のコードを導入しているため、DIスタイルで記述されている間はDI自体、つまりSOLIDのDを使用しないコードへのシフトに気づきました。

要約すれば：

1. テストを簡略化するためにアクセス修飾子が緩められることがある

2. DIは追加のコードを導入します

1と2に照らして、一部の開発者は、これはあまりにも多くの犠牲であり、単純に抽象化に最初から依存することを選択し、後でDIを後から組み込むオプションを選択します。

適切なテストを実行するためにプライベートメソッドを（なんらかの方法で）公開する必要があるというこの概念を特に購入しません。また、クライアント向けAPIはオブジェクトのパブリックメソッドと同じではないことをお勧めします。たとえば、ここにパブリックインターフェイスを示します。

interface IFooDao {
   public Foo GetFoo(int id);
}

そしてあなたの言及はありません FooBuilder

あなたの元の質問では、あなたのを使って3番目のルートをとりますFooBuilder。私はおそらくモックFooDaoを使用してテストし、機能に集中します（簡単であれば、いつでも実際のビルダーを挿入できます）。FooDaoFooBuilder

（この質問/回答でモックが言及されていないことに驚いています-DI / IoCパターンのソリューションのテストと連動しています）

再 あなたのコメント：

前述のように、ビルダーは新しい機能を提供しないため、テストする必要はありませんが、DIPはそれをAPIの一部にしているため、テストする必要があります。

これはあなたがあなたのクライアントに提示するAPIを広げるとは思いません。クライアントがインターフェースを介して使用するAPIを制限できます（希望する場合）。私はまた、あなたのテストがあなたの公開されているコンポーネントを単に囲むべきではないことを提案します。それらは、そのAPIをサポートするすべてのクラス（実装）を包含する必要があります。たとえば、私が現在取り組んでいるシステムのREST APIは次のとおりです。

（疑似コード）

void doSomeCalculation(json : CalculationRequestObject);

私は1つのAPIメソッドと1,000のテストを持っています。これらのテストの大部分は、これをサポートするオブジェクトに関するものです。

この場合、テスト目的でないのに、なぜDIに従う必要があるのですか？公開APIだけでなく、テストもIFooBuilderパラメーター なしで本当にクリーンな場合（書いたとおり）、そのようなクラスを導入しても意味がありません。DIはそれ自体が目的ではなく、コードをよりテストしやすくするのに役立ちます。特定の抽象化レベルの自動テストを記述したくない場合は、そのレベルでDIを適用しないでください。

ただし、FooDaoビルドプロセスなしで単独でコンストラクターの単体テストを作成できるDIを適用したいもののFooDao(IFooBuilder fooBuilder)、パブリックAPIにはコンストラクターは必要なく、コンストラクターのみが必要な場合を想定してみましょうFooDao(IFooConnection fooConnection, IBarConnection barConnection)。次に、前者を「内部」、後者を「パブリック」として提供します。

public class FooDao : IFooDao
{
    private IFooBuilder fooBuilder;

    // only for testing purposes!    
    internal FooDao(IFooBuilder fooBuilder)
    {
        this.fooBuilder = fooBuilder;
    }

    // the public API
    public FooDao(IFooConnection fooConnection, IBarConnection barConnection)
    {
        this.fooBuilder = new FooBuilder(fooConnection, barConnection);
    }    

    public Foo GetFoo(int id)
    {
        return fooBuilder.Build(id);
    }
}

これでFooBuilder、IFooBuilder内部を保持し、InternalsVisibleToユニットテストでアクセスできるようにを適用できます。