Iniezione delle dipendenze nelle prove

Question

Di solito quando si utilizza l'iniezione di dipendenza, i test di unità (e di altro tipo) sono responsabili della creazione/derisione delle dipendenze del sistema sotto test e della loro iniezione.

Tuttavia, a volte il test stesso ha delle dipendenze o ha bisogno di iniettare dipendenze nel SUT che non può creare da sé. Ad esempio, durante il test delle classi che interagiscono con un database, il test deve conoscere stringhe di connessione e nomi di catalogo, ecc., Che non possono essere codificati poiché non sono necessariamente uguali per tutti quelli che eseguono il test.

Quindi, come suggeriresti che un test trovi queste impostazioni? Alcuni framework di test in stile xUnit forniscono un modo per fornire dipendenze a un dispositivo di prova? La classe di test dovrebbe avere proprietà statiche che si popolano prima di eseguire tutti i test? Il test dovrebbe ignorare le pratiche di DI e basta andare a prendere le dipendenze da qualche luogo globale? Altri suggerimenti?

Answer 1

Quando si utilizza il framework di test Unità di fare test di integrazione, è in realtà non hanno un DI o un problema di unità di test.

Quello che hai sono i test di integrazione che sfruttano il quadro ad alta potenza unit testing.

Dal momento che sono i test di integrazione, sono di natura diversa dal test di unità. Il "stand-alone-ness" non conta più.

Il modo migliore per ottenere le impostazioni delle prove di integrazione che variano da utente a utente è quello di ottenere loro lo stesso modo in cui l'applicazione finale farli. Se lavori in Java, potresti avere un file delle proprietà. In Python, abbiamo speciali file di impostazioni di Django per i test di integrazione.

Answer 2

Esiste un principio per i test completamente automatizzati: si dovrebbe essere in grado di estrarre tutto il codice sorgente dal repository di controllo del codice sorgente ed eseguire semplicemente i test.

Dato che l'ambiente (macchina) e la base di installazione corretto (cioè compilatore, framework di test, il motore di database se del caso, ecc) i test sono responsabili della creazione di loro Fixture prima di eseguire i test.

Ciò significa che per i database, i test dovrebbero

1. creare il database in questione
2. fatto il suo test
3. cancellano nuovamente il database dopo l'ultimo banco di prova

Se, per qualche motivo non puoi farlo, l'unica cosa che puoi veramente fare è avere un file di configurazione nel tuo sistema di controllo del codice sorgente che contenga voci specifiche per ogni macchina nei tuoi test invironment; per esempio. per la macchina Tst1 la stringa di connessione è un valore, ma per Tst2 è un altro.

questo può diventare brutto molto velocemente, quindi è molto più facile avere le prove di essere responsabile per il programma di installazione di fissaggio ed Teardown, perché ciò significa che essi possono semplicemente utilizzare i valori hard-coded, o valori generati sul posto.

Questo non ha nulla a che fare con DI ...

Answer 3

DI combatte con dependecies complessità, mentre il test di unità deve essere il più delle volte molto semplice. Il test unitario tipico esaminerebbe un aspetto isolato di una classe isolata. Invece di tutte le sue dipendenze crei mock e (di solito) le inietti tramite il costruttore CUT (Class Under Test). Di solito non hai bisogno di quadri DI qui.

Ma. Alcuni test di livello superiore potrebbero ancora richiedere delle dipendenze non provocate, ovviamente. Ad esempio, si desidera eseguire test su un ampio set di dati e non si desidera creare un'origine dati falsa speciale in modo da mantenerla in un DB reale (forse si eseguono anche alcuni test dell'interfaccia utente con tali dati). In tal caso, proverei ancora a mantenere le cose il più semplice possibile, inizializzando i test nei metodi di configurazione di classe/configurazione di test.

Vedete, dovete stare attenti qui.Ogni volta che esegui un test ampio e complicato:

1. Creare un ulteriore codice complicato, che richiederà sforzi di supporto.
2. creare un test che non ha un chiaro motivo di fallire. Potrebbe non riuscire a causa di una cattiva connettività in quel giorno. Non puoi fare affidamento sul suo risultato.
3. creare un test che non può essere eseguito facilmente e rapidamente, per esempio, al momento del check-in. Meno persone lo eseguiranno, più errori passeranno.

ecc ...