Chi dovrebbe inizializzare le dipendenze in un'applicazione TDD?

8

Sto cercando di imparare a implementare TDD con oggetti finti / falsi. Una delle domande che ho è come inizializzare una dipendenza in un'applicazione che implementa TDD? Un esempio tratto da questo articolo Beginning Mocking With Moq 3 mostra:

public class OrderWriter
{
    private readonly IFileWriter fileWriter;

    public OrderWriter(IFileWriter fileWriter)
    {
        this.fileWriter = fileWriter;
    }

    public void WriteOrder(Order order)
    {
        fileWriter.WriteLine(String.Format("{0},{1}", order.OrderId, order.OrderTotal));
    }
}

In questo esempio, il costruttore prende un parametro IFileWriter , suppongo perché vuoi fornire il vero file writer nel caso dell'applicazione reale e quello falso per il test unitario. La mia domanda è, nella vera applicazione, chi fornirà questo parametro? Suppongo che sarà il chiamante di questa applicazione. Cosa succede se ha dipendenza anche nel costruttore? Il codice del chiamante sarà responsabile anche per questo?

Forse il modo migliore è usare la fabbrica. Come funzionerebbe questa fabbrica? E come sarà distribuita la fabbrica? Sarà nel parametro costruttore come nel modo sopra?

    
posta Louis Rhys 27.08.2012 - 04:10
fonte

2 risposte

7

Quello che stai cercando è un contenitore IoC per rendere automaticamente tutti gli oggetti all'avvio dell'applicazione. Dai un'occhiata a Ninject , ha un esempio molto semplice in prima pagina. (È anche un buon prodotto e ... beh, ninja!)

Come regola generale, dovresti tentare di risolvere tutti gli oggetti di primo livello (ad esempio la pagina in ASP.NET, il controller in MVC per ASP.NET, il modulo in Winforms) direttamente dal contenitore IoC e lasciarlo collegare TUTTE le tue dipendenze tramite l'iniezione del costruttore. Ci saranno momenti in cui devi forzarlo per risolvere un oggetto di livello inferiore - questo è noto come usarlo come Servizio Locator - ma questo dovrebbe generalmente essere evitato in quanto sono difficili (ma non impossibili) da testare e creare un'API che possa essere fonte di confusione per il consumatore, se non sei tu.

ASP.NET per MVC è stato appositamente progettato per astrarre il contenitore IoC dal resto del codice, pur consentendo di autoiniezione in qualsiasi classe di alto livello (Controller, Visualizza, Filtro, ecc.) tramite la classe DependencyResolver . Altri framework .NET richiedono un po 'più impegno, ma è possibile che tu sia su Google.

C'è un libro sull'argomento chiamato Iniezione delle dipendenze in .NET . Non l'ho letto personalmente, ma ho sentito cose buone.

    
risposta data 27.08.2012 - 05:52
fonte
0

Ho visto l'approccio di aggiungere un costruttore predefinito che chiama il costruttore parametrizzato con istanze predefinite, ad esempio "Iniezione di dipendenza da uomo povero".

public OrderWriter()
    : this(new TextFileWriter())
{
}

Il normale percorso del codice chiama il costruttore predefinito, mentre il test dell'unità inizializza usando il costruttore personalizzato.

Se qualcuno potesse approfondire i pro ei contro di questo approccio, lo apprezzerei molto.

    
risposta data 14.06.2016 - 13:04
fonte

Leggi altre domande sui tag