Forse sto mostrando la mia mancanza di comprensione dell'input di dipendenza e dei test, ma non capisco come l'uso di dependency injection con classi che non implementano interfacce mi aiuti affatto con i test?Codice di test dipendente dalla libreria Enterprise anche se non fornisce interfacce?
Ad esempio, nella documentazione di Enterprise Library 5.0 si parla dell'utilizzo del contenitore Unity per creare istanze. Dice che questo aiuta "testabilità: è banale isolare le classi dalle dipendenze quando si utilizza lo stile di iniezione delle dipendenze". MSDN
Come si utilizza questo dispositivo di prova dell'unità? Il loro esempio ha un costruttore con parametri come classi piuttosto che interfacce:
public class TaxCalculator
{
private ExceptionManager _exceptionManager;
private LogWriter _logWriter;
public TaxCalculator(ExceptionManager em, LogWriter lw)
{
this._exceptionManager = em;
this._logWriter = lw;
}
}
Ho cambiato il titolo per riflettere sul fatto che non voglio testare Enterprise Library ma il mio codice personale dipende da Enterprise Library. –
Ho aggiornato la risposta per parlare esplicitamente di come testare il proprio codice alla luce delle dipendenze esterne. –
Btw definisce le proprie interfacce che descrivono le esigenze della vostra applicazione (ad esempio la registrazione). La separazione dell'infrastruttura dal codice aziendale è ottima. Ma perdere le caratteristiche del framework, aggiungere un altro livello di astrazione, perdere ottimizzazioni e prestazioni, non è sicuramente positivo. –