IReaderインターフェイス、IReaderインターフェイスReaderImplementationの実装、およびリーダーからのデータを消費して処理するクラスReaderConsumerを想定しています。

public interface IReader
{
     object Read()
}

実装

public class ReaderImplementation
{
    ...
    public object Read()
    {
        ...
    }
}

消費者：

public class ReaderConsumer()
{
    public string location

    // constructor
    public ReaderConsumer()
    {
        ...
    }

    // read some data
    public object ReadData()
    {
        IReader reader = new ReaderImplementation(this.location)
        data = reader.Read()
        ...
        return processedData    
    }
}

ReaderConsumerと処理のテストには、IReaderのモックを使用します。ReaderConsumerは次のようになります。

public class ReaderConsumer()
{
    private IReader reader = null

    public string location

    // constructor
    public ReaderConsumer()
    {
        ...
    }

    // mock constructor
    public ReaderConsumer(IReader reader)
    {
        this.reader = reader
    }

    // read some data
    public object ReadData()
    {
        try
        {
            if(this.reader == null)
            {
                 this.reader = new ReaderImplementation(this.location)
            }

            data = reader.Read()
            ...
            return processedData    
        }
        finally
        {
            this.reader = null
        }
    }
}

このソリューションでは、モック作成コンストラクターのみがインターフェイスのインスタンスを提供するため、モック作成には実動コードのif文が導入されます。

これを書いている間、try-finallyブロックは、アプリケーションの実行中に場所を変更するユーザーを処理するために存在するため、やや無関係であることがわかりました。

全体的に臭いが感じられますが、どうすればより良く処理できますか？

メソッドからリーダーを初期化する代わりに、この行を移動します

{
    this.reader = new ReaderImplementation(this.location)
}

デフォルトのパラメーターなしのコンストラクターに。

public ReaderConsumer()
{
    this.reader = new ReaderImplementation(this.location)
}

public ReaderConsumer(IReader reader)
{
    this.reader = reader
}

「モックコンストラクター」のようなものはありません。クラスが動作するために必要な依存関係を持っている場合、コンストラクターはそのモノを提供するか、作成する必要があります。

必要なコンストラクタは1つだけです。

public class ReaderConsumer()
{
    private IReader reader = null

    public string location

    // constructor
    public ReaderConsumer(IReader reader)
    {
        this.reader = reader;
    }

本番コードで：

var rc = new ReaderConsumer(new ReaderImplementation(0));

あなたのテストで：

var rc = new ReaderConsumer(new MockImplementation(0));

依存性注入と制御の反転を調べる

ユアンとラバーダックの両方に優れた答えがあります。しかし、依存性注入（DI）と制御の反転（IoC）を調べる別の領域に言及したかったです。これらのアプローチは両方とも、あなたが経験している問題をフレームワーク/ライブラリに移動するので、心配する必要はありません。

あなたの例は単純で、すぐに省かれますが、必然的にあなたはそれに基づいて構築するつもりであり、あなたは次のようなたくさんのコンストラクタまたは初期化ルーチンのいずれかになるでしょう：

var foo = new Foo（new Bar（new Baz（）、new Quz（））、new Foo2（））;

DI / IoCでは、インターフェイスを実装に一致させるための規則を綴るライブラリを使用し、「Goo me a Foo」と言うだけで、すべてを接続する方法がわかります。

非常に友好的なIoCコンテナ（と呼ばれる）がたくさんありますので、検討することをお勧めしますが、すばらしい選択肢がたくさんあるので、探ってください。

最初に簡単なものは次のとおりです。

http://www.ninject.org/

探索するリストは次のとおりです。

http://www.hanselman.com/blog/ListOfNETDependencyInjectionContainersIOC.aspx