Ho intitolato scherzosamente la domanda perché sono sicuro che "dipende", ma ho alcune domande specifiche.
Lavorando in un software che ha molti strati profondi di dipendenza, il mio team si è abituato a usare il mocking abbastanza estensivamente per separare ogni modulo di codice dalle dipendenze sottostanti.
Pertanto sono rimasto sorpreso dal fatto che Roy Osherove suggerito in questo video che dovresti usare solo per deridere qualcosa come il 5% delle volte. Immagino che siamo seduti da qualche parte tra il 70% e il 90%. Ho visto altre indicazioni simili di volta in volta.
Dovrei definire quelle che considero due categorie di "test di integrazione" che sono così distinti che dovrebbero avere nomi diversi: 1) test in-process che integrano più moduli di codice e 2) Out-of-process test che parlano di database, file system, servizi web, ecc. È il tipo # 1 di cui mi occupo, test che integrano più moduli di codice in-process.
Gran parte delle linee guida della community che ho letto suggerisce che dovresti preferire un gran numero di test unitari a grana fine e un piccolo numero di test di integrazione end-to-end a grana grossa, perché i test unitari ti forniscono un feedback preciso esattamente dove le regressioni potrebbero essere state create, ma i test approssimativi, che sono complicati da configurare, verificano effettivamente più funzionalità end-to-end del sistema.
Dato questo, sembra necessario fare un uso piuttosto frequente del mocking per isolare queste unità separate di codice.
Dato un modello di oggetto come segue:
...Considerateanchechelaprofonditàdelledipendenzedellanostraapplicazionevamoltopiùinprofonditàdiquantopotreiinserireinquestaimmagine,inmodochecisianopiùlivelliNtraillivello2-4eillivello5-13.
Sevogliotestarealcunesemplicidecisionilogichefattenell'unità#1,eseognidipendenzaèiniettatadalcostruttorenelmodulodicodicechedipendedaessoinmodotaleche,peresempio,2,3e4sonoiniettatiinuncostruttoremodulo1nell'immagine,preferireimoltodipiùleiniezionidi2,3e4in1.
Altrimenti,avreibisognodicostruireistanzeconcretedi2,3e4.Questopuòesserepiùdifficilediunadigitazioneinpiù.Spesso2,3e4avrannorequisitidicostruttorechepossonoesseredifficilidasoddisfareeinbasealgrafico(einbaseallarealtàdelnostroprogetto),avròbisognodicostruireistanzeconcretedaNa13persoddisfareicostruttoridi2,3e4.
Questasituazionediventapiùdifficilequandohobisognodi2,3o4percomportarmiinuncertomodoinmododapotertestarelasemplicedecisionelogicaalpunto#1.Potreiaverbisognodicapiree"ragionare mentalmente" sull'intero oggetto grafico / albero tutto in una volta per ottenere 2, 3 o 4 da comportarsi nel modo necessario. Spesso sembra molto più semplice eseguire myMockOfModule2.Setup (x = > x.GoLeftOrRight ()). Restituisce (new Right ()); per verificare che il modulo 1 risponda come previsto quando il modulo 2 dice di andare a destra.
Se dovessi testare istanze concrete di 2 ... N ... 13 tutte insieme, le impostazioni di test sarebbero molto grandi e per lo più duplicate. I fallimenti dei test potrebbero non fare un ottimo lavoro per individuare le posizioni dei guasti delle regressioni. I test non sarebbero indipendente ( un altro link di supporto ).
Certo, è spesso ragionevole effettuare test basati sullo stato, piuttosto che su base interattiva, dal momento che questi moduli raramente hanno un'ulteriore dipendenza. Ma sembra che il mocking sia quasi necessario per definizione per isolare tutti i moduli al di sopra del punto più basso.
Dato tutto questo, qualcuno può dirmi cosa potrei perdere? La nostra squadra sta abusando di mock? O forse c'è qualche ipotesi nella tipica guida per i test unitari che gli strati di dipendenza nella maggior parte delle applicazioni saranno abbastanza superficiali da rendere davvero ragionevole testare tutti i moduli di codice integrati (rendendo il nostro caso "speciale")? O forse in modo diverso, il nostro team non sta vincolando adeguatamente i nostri contesti limitati?