Quali tipi di bug possono effettivamente trovare i test di integrazione?

Ti darò 2 esempi:

Una cosa banale, una volta ho visto una classe di rete che ti permetteva di impostare l'host e la porta e quindi inviare messaggi. Il test delle unità ha funzionato: è possibile impostare l'host, è possibile impostare la porta, è possibile chiamare il metodo che ha inviato messaggi.

Durante l'integrazione, qualcuno ha scritto il codice client che utilizzava questa classe e impostava la porta prima di impostare l'host. Nulla ha funzionato, perché il metodo host set ripristina la porta su un valore predefinito.

Questo è un esempio semplice e semplice che mostra che i test delle unità possono mostrare un comportamento corretto, ma poiché i metodi non sono stati chiamati nel modo previsto, non sono riusciti in fase di runtime. Si potrebbe obiettare che i test unitari non erano corretti, in quanto non testavano tutte le combinazioni delle chiamate di impostazione delle proprietà, ma il test unitario ha lo scopo di garantire che ogni sezione del codice funzioni correttamente (ad esempio imposta la proprietà corretta) e non come l'interazione tra quindi si verifica. (Ovviamente, sarebbe meglio sostenere che la classe avrebbe dovuto essere l'unità di test qui e che potrebbe aver catturato questo bug, ma anche così dubito che qualcuno avrebbe ripetuto il test con diverse combinazioni di setup di proprietà).

Un altro esempio è con il threading. Ho avuto una classe che ha funzionato perfettamente nei test di unità, ci vuole un blocco su una risorsa condivisa e chiama un metodo su un oggetto diverso, che come tale metodo viene deriso, ritorna immediatamente. Nel mondo reale, quel metodo in realtà fa molto più lavoro, crea un nuovo thread che aspetta che la stessa risorsa condivisa diventi disponibile, e quindi sblocca l'intero programma. Buona fortuna a trovarlo nei test unitari.

I test unitari non sono i test principali che dovresti fare. In effetti, se si dovesse avere solo un livello di test, sarebbe un test di integrazione. I test unitari sono un modo "veloce e sporco" di superare gli ovvi bug sollevati durante lo sviluppo e sono più di un controllo dello sviluppatore per assicurarsi di non aver fatto nulla di stupido (come quando ho scritto una classe aritmetica che è stata aggiunta quando hai chiamato l'operatore di sottrazione .. un test unitario avrebbe catturato quella piaga e incolla pigrizia). Questo è tutto ciò che dovrebbero essere lì per se, cercando di garantire un funzionamento perfetto del sistema che li utilizza è fuorviante.

I test di integrazione sono i primi test in cui due o più componenti di sistema reali (cioè non in derisione) interagiscono tra loro. Se si hanno sia test di unità che di integrazione, un test di integrazione non riuscito è un strong indicatore del fatto che il comportamento del mock per il componente A non corrisponde al comportamento del componente reale A.

Specialmente in un sistema più grande, è facile creare una disconnessione tra il comportamento del componente reale e il comportamento previsto codificato nei mock e il loro utilizzo.

Dipende un po 'dal sistema che stai testando, ma possono trovare molte cose che non sono coperte da bei test di unità stateless.

Per me il più grande sta parlando al database. Puoi avere i tuoi test unitari su cose che decidono di parlare al database, e puoi fare il test dell'unità su cose che girano all'interno del database (a volte, con alcuni trucchi sporchi), ma hai bisogno di test di integrazione per assicurarti che queste cose possano tutti si parlano correttamente. L'interfaccia database / applicazione è in genere piuttosto fragile, quindi è importante avere i test su quanto più possibile.

I sistemi che contengono più componenti che comunicano tramite REST o un bus di messaggi traggono enorme vantaggio dai test di integrazione per verificare che i componenti possano effettivamente funzionare tra loro nel modo in cui dovrebbero. Potrebbero entrambi avere una copertura di test unitaria completa sulle loro interfacce esterne, ma l'idea di Frobnicator dell'interfaccia pubblica del Mungeifier corrisponde all'interfaccia pubblica effettivamente fornita dal Mungeifier? Anche i componenti più liberamente accoppiati immaginabili devono conformarsi a un qualche tipo di contratto di interfaccia o la comunicazione diventa del tutto impossibile. Tutto questo deve essere testato, e l'unico modo per essere sicuri è testarlo per davvero.

Inoltre, è possibile visualizzare il test delle prestazioni come una sorta di test di integrazione. Non solo stai testando se il sistema può funzionare sotto i carichi previsti, perché testerai l'intero sistema come assemblato per la produzione (o dovresti esserlo), stai anche facendo test di integrazione sul carico di lavoro delle prestazioni. Pertanto, l'imbracatura per test delle prestazioni deve essere in grado di individuare errori comportamentali e caratteristiche prestazionali. Non va bene essere veloci se ti sbagli!