In un codebase con tutte le dipendenze iniettate, l'unità può testare le regressioni di cattura?

Question

In un codebase con tutte le dipendenze iniettate, l'unità può testare le regressioni di cattura?

#1 da (4 voti)
#2 da (2 voti)

2

Diciamo che costruisco il mio codice in modo da iniettare TUTTE le dipendenze a ogni classe e quando eseguo il test, sostituisco queste dipendenze con i test double. Diciamo anche che quando lavoro in una classe faccio i suoi test per testarlo. Dato che una regressione è un errore imprevisto in una parte della base di codice diversa da quella che ho modificato, deve essere dovuto al codice (ad esempio nella classe X) che ha una dipendenza da un codice che ho modificato in seguito a una modifica del comportamento del mio codice. Tuttavia, le dipendenze della classe X sono state sostituite con doppie di test quando è in fase di test e quelle non sono state modificate. Pertanto i test unitari su X non falliranno. Pertanto i miei test unitari non prenderanno alcuna regressione causata dai miei cambiamenti.

È corretto?

(Non sono interessato a una spiegazione del motivo per cui è necessario che i test unitari non testino le dipendenze, presumo che sia il caso e chiedo le conseguenze)

unit-testing dependency-injection

posta James Ellis-Jones 27.06.2018 - 12:21

fonte

2 risposte

2

Se definisci il termine "regressione" come un errore in un'unità diverso da quello che è stato cambiato, e usi il termine "unit test" in senso stretto per testare esclusivamente le unità isolate (e non nel modo pragmatico che molte persone fanno spesso quando parlano effettivamente di test automatici), allora sei corretto - questo tipo di test unitari non troveranno regressioni di questo genere per definizione .

Ecco perché hai anche bisogno dei test di regressione , idealmente automatizzati. E quando si attengono alla tua formulazione, questi sono esclusivamente test di integrazione.

Nota, tuttavia, la maggior parte delle persone non usa il termine "regressioni" in un senso così ristretto. Un cambiamento in una parte di una unità può causare un inatteso, non intenzionale cambiamento di comportamento in quell'unità , e il termine "regressioni" viene in genere utilizzato anche per quello.

risposta data 27.06.2018 - 12:56

fonte

Leggi altre domande sui tag unit-testing dependency-injection

Livello corretto per gestire chiavi duplicate come ripristinare l'arresto di alimentazione mentre si aggiorna automaticamente la mia applicazione

score 4 · Accepted Answer

È corretto. Ed è il difetto fondamentale con la vista reductio ad absurdum che i test unitari devono solo testare una singola "unità" di codice e che tutto il resto dovrebbe essere deriso.

Se si adotta l'approccio di visione molto più ragionevole di una "unità" come un pezzo di funzionalità che può essere eseguito in isolamento (cioè, non ha effetti collaterali, quindi può essere testato in parallelo), quindi questo intero problema va via . Sostituisci solo le dipendenze con i duplicati di test quando necessario . Se tale dipendenza ha un effetto collaterale o è lenta, spingere a testare tale interazione nei test di integrazione. Altrimenti lasciatelo al suo posto in modo che i test unitari formino utili test di regressione.

Se segui quella posizione estrema su beffardo di tutto, allora finirai di dover scrivere molti test di integrazione per fornire quel test di regressione. Il che quindi fa sorgere la domanda, a cosa servono quei test unitari, in quanto non devono quindi fornire test di regressione?