Supponendo un'interfaccia IReader, un'implementazione dell'interfaccia IReader ReaderImplementation e una classe ReaderConsumer che consuma ed elabora i dati dal lettore.

public interface IReader
{
     object Read()
}

Implementazione

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

Consumatore:

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    
    }
}

Per testare ReaderConsumer e l'elaborazione uso una simulazione di IReader. Quindi ReaderConsumer diventa:

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
        }
    }
}

In questa soluzione il derisione introduce una frase if per il codice di produzione poiché solo il costruttore di simulazione fornisce un'istanza dell'interfaccia.

Durante la stesura di questo, mi rendo conto che il blocco try-finally è in qualche modo non correlato poiché è lì per gestire l'utente che modifica la posizione durante il runtime dell'applicazione.

Nel complesso sembra puzzolente, come potrebbe essere gestito meglio?

Invece di inizializzare il lettore dal tuo metodo, sposta questa riga

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

Nel costruttore senza parametri predefinito.

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

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

Non esiste un "costruttore finto", se la tua classe ha una dipendenza che richiede per funzionare, allora al costruttore dovrebbe essere fornita quella cosa o crearla.

Hai solo bisogno del singolo costruttore:

public class ReaderConsumer()
{
    private IReader reader = null

    public string location

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

nel tuo codice di produzione:

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

nel tuo test:

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

Esaminare l'iniezione di dipendenza e l'inversione del controllo

Sia Ewan che RubberDuck hanno risposte eccellenti. Ma volevo menzionare un'altra area in cui esaminare Dependency Injection (DI) e Inversion of Control (IoC). Entrambi questi approcci spostano il problema riscontrato in un framework / libreria in modo da non doversi preoccupare.

Il tuo esempio è semplice e viene rapidamente eliminato, ma inevitabilmente ti baserai su di esso e finirai con tonnellate di costruttori o routine di inizializzazione che assomigliano a:

var foo = new Foo (nuova barra (nuova Baz (), nuova Quz ()), nuova Foo2 ());

Con DI / IoC usi una libreria che ti permette di precisare le regole per abbinare le interfacce alle implementazioni e poi dici semplicemente "Give me a Foo" e scopre come collegare tutto.

Ci sono molti contenitori IoC molto amichevoli (come vengono chiamati) là fuori, e ho intenzione di raccomandarne uno da guardare, ma, per favore, esplora, poiché ci sono molte scelte eccellenti.

Uno semplice per cominciare è:

http://www.ninject.org/

Ecco un elenco da esplorare:

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