Test di integrazione e stringa di connessione al database in app.config

5

Sto lavorando su un progetto in cui SqlConnection viene creato tramite un metodo statico, diciamo che è DatabaseAccess.GetSqlConnection() . Questo metodo legge il file .config per ottenere la stringa di connessione e crea una connessione.

È corretto refactoring il codice per utilizzare un ISqlConnectionCreator (o ISqlConnectionFactory ) responsabile della creazione delle connessioni effettive solo per motivi di test (come sembra di più "dal libro "per me) o andare facile e basta creare un file .config nel progetto di test contenente le stringhe di connessione di test?

La seconda soluzione sembra più soggetta a errori e crea una relazione indiretta tra i test e le classi testate.

Voglio assicurarmi che ci sia una giustificazione per il lavoro extra di refactoring del codice per utilizzare il creatore della connessione iniettata.

    
posta user1713059 28.03.2015 - 17:48
fonte

2 risposte

1

Da una visione pragmatica suggerirei di utilizzare qualsiasi cosa funzioni meglio, con il minimo sforzo di manutenzione.

In questa situazione specifica, probabilmente andrei con "opzione 3": separa la parte che legge la stringa di connessione dalla parte che crea la connessione effettiva in due metodi diversi. Pertanto, la stringa di connessione diventa un parametro di input del metodo 2 e nel codice di test è possibile omettere la valutazione di configurazione e fornire la stringa di connessione di test in qualsiasi modo, ad esempio, come parte dei dati di test codificati. Di conseguenza, non è necessario un file di configurazione di test, né un ISqlConnectionCreator .

    
risposta data 28.03.2015 - 20:06
fonte
-1

Ho difficoltà a vedere i benefici di questo codice extra. Il codice è una responsabilità e, a meno che non ci sia un problema reale, probabilmente non vorrei passare del tempo.

Vorrei solo creare il file app.config e chiamarlo un giorno.

    
risposta data 27.07.2015 - 14:16
fonte

Leggi altre domande sui tag