Codice di test dipendente dalla libreria Enterprise anche se non fornisce interfacce?

Question

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?

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

Answer 1

Per rispondere alla domanda "Come verificare il codice libreria aziendale": non lo si. Testare le cose degli altri è compito di altre persone. Qualsiasi interfaccia o astrazione in Enterprise Library o qualsiasi altra libreria di terze parti esiste per i propri scopi di astrazione, non per il proprio.

Quello che devi fare è definire le tue interfacce che descrivono le esigenze della tua applicazione (registrazione, memorizzazione nella cache, crittografia, ecc.) E quindi scrivere adattatori che implementano le tue interfacce usando Enterprise Library (o altre librerie di terze parti) . Questa pratica è nota come Dependency Inversion Principle.

Per testare il proprio codice progettato in questo modo, per i test a livello di unità/componente si utilizza semplicemente Test Doubles per le interfacce definite dall'utente (ad es. IMyOwnLogger). Per testare gli adattatori che scrivi per adattarli alle librerie di terze parti, devi scrivere test di integrazione. Per verificare che funzioni tutti insieme, scriveresti test di accettazione che guidano l'app attraverso l'interfaccia utente o sottocutanea.

Per ulteriori informazioni su questa vista, controlla il mio articolo: "TDD Best Practices: Don't Mock Others".

Answer 2

È preferibile programmare contro l'astrazione anziché l'implementazione. Ma l'astrazione non è sempre l'interfaccia. Potrebbe essere una classe astratta.

public abstract class LogWriter 
{ 
    public abstract void Write(string message); 
} 

Quindi, non c'è nessun problema di creare finta di classe astratta:

Mock<LogWriter> logWriter = new Mock<LogWriter>(); 
TaxCalculator calc = new TaxCalculator(logWriter.Object); 

Se non fare unit test, non vedo alcun problema passare parametri non astratte, perché del principio YAGNI. Se non ho bisogno di un'altra implementazione di ExceptionManager, perché dovrei creare un'astrazione su di essa? Ma se faccio TDD, allora sicuramente avrò bisogno di almeno due implementazioni di classe. Uno vero e uno finto/mozzo.

Fare attenzione con service locator anti-pattern.

AGGIORNAMENTO: non è stato possibile riferirsi alle classi esistenti di Microsoft.Practices.EnterpriseLibrary (che non mi piace). Penso che questo sia un altro fallimento di progettazione del team di Microsoft.Practices. La classe ExceptionManager "sealed" che non implementa alcuna interfaccia/classe base uccide la testabilità.

Answer 3

Fintanto che le classi non sono sealed, un quadro di simulazione esperto può creare una sottoclasse che agisce esattamente come un'implementazione di un'interfaccia fittizia. Ci sono più considerazioni da fare quando si dipende da classi concrete - i metodi sealed continueranno ad essere eseguiti sulla classe specificata, ecc. - ma in generale non è diverso da a seconda dell'interfaccia.