Ho intitolato la domanda scherzosamente perché sono sicuro che "dipende", ma ho alcune domande specifiche.
Lavorando in un software che ha molti profondi livelli di dipendenza, il mio team si è abituato a deridere in modo abbastanza esteso per separare ciascun modulo di codice dalle dipendenze sottostanti.
Pertanto sono rimasto sorpreso dal fatto che Roy Osherove abbia suggerito in questo video che si dovrebbe usare beffardo solo qualcosa come il 5% delle volte. Immagino che siamo seduti da qualche parte tra il 70-90%. Di tanto in tanto ho visto anche altre indicazioni simili .
Dovrei definire quelle che considero due categorie di "test di integrazione" che sono così distinti che dovrebbero davvero avere nomi diversi: 1) Test in-process che integrano più moduli di codice e 2) Test out-of-process che parlano a database, file system, servizi web, ecc. È il tipo 1 di cui mi occupo, test che integrano più moduli di codice tutti in-process.
Gran parte della guida della comunità che ho letto suggerisce che dovresti preferire un gran numero di test unitari a grana fine isolati e un piccolo numero di test di integrazione end-to-end a grana grossa, perché i test unitari forniscono un feedback preciso esattamente dove le regressioni potrebbero essere state create, ma i test grossolani, che sono ingombranti da configurare, in realtà verificano più funzionalità end-to-end del sistema.
Detto questo, sembra necessario fare un uso piuttosto frequente del derisione per isolare queste unità di codice separate.
Dato un modello a oggetti come segue:
... Considera anche che la profondità di dipendenza della nostra applicazione va molto più in profondità di quanto potrei adattarmi in questa immagine, in modo che ci siano più livelli N tra il livello 2-4 e il livello 5-13.
Se voglio testare qualche semplice decisione logica presa nell'unità n. 1, e se ogni dipendenza viene iniettata dal costruttore nel modulo di codice che dipende da essa in modo tale, per esempio, che 2, 3 e 4 siano iniettati dal costruttore nel modulo 1 in l'immagine, preferirei piuttosto iniettare simulazioni di 2, 3 e 4 in 1.
Altrimenti, avrei bisogno di costruire istanze concrete di 2, 3 e 4. Questo può essere più difficile di una semplice digitazione extra. Spesso 2, 3 e 4 avranno requisiti di costruzione che possono essere difficili da soddisfare e secondo il grafico (e secondo la realtà del nostro progetto), dovrò costruire istanze concrete di N fino a 13 per soddisfare i costruttori di 2, 3 e 4.
Questa situazione diventa più difficile quando ho bisogno di 2, 3 o 4 per comportarmi in un certo modo in modo da poter testare la semplice decisione logica in # 1. Potrei aver bisogno di capire e "ragionare mentalmente" l'intero oggetto grafico / albero tutto in una volta per far sì che 2, 3 o 4 si comportino nel modo necessario. Spesso sembra molto più semplice eseguire myMockOfModule2.Setup (x => x.GoLeftOrRight ()). Returns (new Right ()); per testare che il modulo 1 risponde come previsto quando il modulo 2 gli dice di andare bene.
Se dovessi testare istanze concrete di 2 ... N ... 13 tutte insieme, le configurazioni del test sarebbero molto grandi e per lo più duplicate. Gli errori di test potrebbero non fare un ottimo lavoro nell'individuare le posizioni degli errori di regressione. I test non sarebbero indipendenti ( un altro link di supporto ).
Certo, è spesso ragionevole fare test basati sullo stato, piuttosto che sull'interazione, del livello inferiore, dal momento che quei moduli raramente hanno ulteriori dipendenze. Ma sembra che il deridere sia quasi necessario per definizione per isolare qualsiasi modulo al di sopra del fondo.
Alla luce di tutto ciò, qualcuno può dirmi cosa potrei perdere? Il nostro team sta abusando delle beffe? O c'è forse qualche ipotesi nella tipica guida ai test unitari secondo cui gli strati di dipendenza nella maggior parte delle applicazioni saranno abbastanza superficiali da poter ragionevolmente testare tutti i moduli di codice integrati insieme (rendendo il nostro caso "speciale")? O forse diversamente, il nostro team non delimita adeguatamente i nostri contesti limitati?
Or is there perhaps some assumption in typical unit testing guidance that the layers of dependency in most applications will be shallow enough that it is indeed reasonable to test all of the code modules integrated together (making our case "special")? <- Questo.