Qual è la differenza tra integrazione e unit test?


307

Conosco la cosiddetta definizione da manuale di unit test e test di integrazione. Ciò di cui sono curioso è quando è il momento di scrivere unit test ... li scriverò per coprire il maggior numero possibile di classi.

Ad esempio, se ho una Wordclasse, scriverò alcuni test unitari per la Wordclasse. Quindi, comincio a scrivere la mia Sentenceclasse e quando ha bisogno di interagire con la Wordclasse, scrivo spesso i miei test unitari in modo che testino entrambi Sentencee Word... almeno nei luoghi in cui interagiscono.

Questi test sono diventati essenzialmente test di integrazione perché ora testano l'integrazione di queste 2 classi o è solo un test unitario che si estende su 2 classi?

In generale, a causa di questa linea incerta, raramente scriverò test di integrazione ... o sto usando il prodotto finito per vedere se tutti i pezzi funzionano correttamente i test di integrazione effettivi, anche se sono manuali e raramente ripetuti oltre lo scopo di ogni singola caratteristica?

Sto fraintendendo i test di integrazione o c'è davvero poca differenza tra l'integrazione e i test unitari?

Risposte:


300

La differenza fondamentale, secondo me, è che i test di integrazione rivelano se una funzionalità funziona o è rotta, poiché sottolineano il codice in uno scenario vicino alla realtà. Invocano uno o più metodi o funzionalità del software e verificano se agiscono come previsto.

Al contrario, un test unitario che verifica un singolo metodo si basa sul presupposto (spesso sbagliato) che il resto del software funzioni correttamente, perché prende in giro esplicitamente ogni dipendenza.

Pertanto, quando un unit test per un metodo che implementa alcune funzionalità è verde, ciò non significa che la funzionalità funzioni.

Supponi di avere un metodo da qualche parte come questo:

public SomeResults DoSomething(someInput) {
  var someResult = [Do your job with someInput];
  Log.TrackTheFactYouDidYourJob();
  return someResults;
}

DoSomethingè molto importante per il tuo cliente: è una caratteristica, l'unica cosa che conta. Ecco perché di solito scrivi una specifica del cetriolo affermandola: desideri verificare e comunicare se la funzione funziona o meno.

Feature: To be able to do something
  In order to do something
  As someone
  I want the system to do this thing

Scenario: A sample one
  Given this situation
  When I do something
  Then what I get is what I was expecting for

Senza dubbio: se il test ha esito positivo, puoi affermare che stai offrendo una funzionalità funzionante. Questo è ciò che puoi chiamare Business Value .

Se vuoi scrivere un test unitario DoSomethingdovresti far finta (usando alcune simulazioni) che il resto delle classi e dei metodi stiano funzionando (cioè che tutte le dipendenze che il metodo sta usando stiano funzionando correttamente) e affermare che il tuo metodo sta funzionando.

In pratica, fai qualcosa del tipo:

public SomeResults DoSomething(someInput) {
  var someResult = [Do your job with someInput];
  FakeAlwaysWorkingLog.TrackTheFactYouDidYourJob(); // Using a mock Log
  return someResults;
}

Puoi farlo con Dependency Injection, o qualche metodo Factory o qualsiasi Mock Framework o semplicemente estendendo la classe sotto test.

Supponiamo che ci sia un bug Log.DoSomething(). Fortunatamente, le specifiche Gherkin lo troveranno e i tuoi test end-to-end falliranno.

La funzione non funzionerà, perché Logè rotta, non perché [Do your job with someInput]non sta facendo il suo lavoro. E, a proposito, [Do your job with someInput]è la sola responsabilità di quel metodo.

Supponiamo inoltre che Logvenga utilizzato in altre 100 funzioni, in altri 100 metodi di altre 100 classi.

Sì, 100 funzioni falliranno. Ma, fortunatamente, anche 100 test end-to-end stanno fallendo e stanno rivelando il problema. E sì: stanno dicendo la verità .

Sono informazioni molto utili: so di avere un prodotto rotto. Sono anche informazioni molto confuse: non mi dice nulla su dove si trovi il problema. Mi comunica il sintomo, non la causa principale.

Tuttavia, DoSomethingil test unitario è verde, perché utilizza un falso Log, costruito per non rompersi mai. E sì: sta chiaramente mentendo . Sta comunicando che una funzionalità non funzionante funziona. Come può essere utile?

(Se DoSomething()il test unitario fallisce, assicurati: [Do your job with someInput]ha alcuni bug.)

Supponiamo che questo sia un sistema con una classe rotta: Un sistema con una classe rotta

Un singolo bug interromperà diverse funzionalità e vari test di integrazione falliranno.

Un singolo bug interromperà diverse funzionalità e vari test di integrazione falliranno

D'altra parte, lo stesso bug interromperà solo un test unitario.

Lo stesso bug interromperà solo un test unitario

Ora confronta i due scenari.

Lo stesso bug interromperà solo un test unitario.

  • Tutte le tue funzionalità che usano il rotto Logsono rosse
  • Tutti i test unitari sono verdi, solo il test unitario Logè rosso

In realtà, i test unitari per tutti i moduli che utilizzano una funzionalità non funzionante sono verdi perché, usando i mock, hanno rimosso le dipendenze. In altre parole, corrono in un mondo ideale, completamente immaginario. E questo è l'unico modo per isolare i bug e cercarli. Test unitario significa beffardo. Se non stai deridendo, non stai testando l'unità.

La differenza

I test di integrazione indicano cosa non funziona. Ma non servono a indovinare dove potrebbe essere il problema.

I test unitari sono gli unici test che indicano dove si trova esattamente il bug. Per disegnare queste informazioni, devono eseguire il metodo in un ambiente deriso, dove tutte le altre dipendenze dovrebbero funzionare correttamente.

Ecco perché penso che la tua frase "O è solo un test unitario che si estende su 2 classi" è in qualche modo spostata. Un test unitario non dovrebbe mai comprendere 2 classi.

Questa risposta è fondamentalmente un riassunto di ciò che ho scritto qui: I test unitari mentono, ecco perché li adoro .


6
Una risposta davvero buona! Tuttavia, voglio solo aggiungere che il derisione non è solo per unit test. Potrebbe anche essere molto utile in molti casi di test di integrazione.
n.Stenvang,

1
Bella risposta! Non sono assolutamente d'accordo con due punti: 1) che i test di integrazione sono "inutili per indovinare dove potrebbe essere il problema"; e 2) che "un test unitario non dovrebbe mai superare 2 classi". Ho creato molti test di integrazione e, quando si interrompono, di solito non è difficile individuare l'origine del problema, a condizione che si ottenga una traccia dello stack completa o una singola asserzione non riuscita (nel qual caso può essere più difficile trovare l'origine, ma non tanto, poiché il test di integrazione fornisce un contesto contenuto per il debug). (continua)
Rogério,

5
I test unitari possono esercitare più classi, a condizione che non siano classi pubbliche che dovrebbero avere i propri test unitari separati. Un caso è quando una classe testata pubblica usa altre classi helper non pubbliche che esistono solo per supportare la classe pubblica; in questo caso, l '"unità" comprende due o più classi. Un altro caso è che la maggior parte delle classi usa classi di terze parti (la classe String / string, le classi di raccolta, ecc.) Che non hanno senso essere derise o isolate; li consideriamo semplicemente come dipendenze stabili e affidabili che non rientrano nell'ambito del test.
Rogério,

2
Con i test di integrazione è un po 'più difficile trovare il problema di root, ma puoi ancora eseguirne il debug e trovare il problema di root. Supponendo che i test unitari non falliscano spesso, quindi forse raramente ci vorrà un po 'più di tempo per correggere i bug se si hanno solo test di integrazione, ma poi si ottiene anche il valore aggiunto di testare l'integrazione dei componenti e si risparmia il tempo di scrittura i test unitari. Penso che questa affermazione (che proviene dal mio capo) sia sbagliata, ma non sono sicuro come posso convincerlo, qualche idea?
BornToCode

1
Basandosi sul ragionamento di questa risposta, si potrebbe sostenere che potrebbe essere più efficace saltare la scrittura di unit test e trascorrere il tempo risparmiato individuando l'origine dei test di integrazione non riusciti quando falliscono.

62

Quando scrivo unit test, limito l'ambito del codice testato alla classe che sto attualmente scrivendo deridendo le dipendenze. Se scrivo una classe Frase e Frase ha una dipendenza da Word, userò una parola finta. Deridendo Word posso concentrarmi solo sulla sua interfaccia e testare i vari comportamenti della mia classe Frase mentre interagisce con l'interfaccia di Word. In questo modo sto solo testando il comportamento e l'implementazione di Frase e non allo stesso tempo testando l'implementazione di Word.

Dopo aver scritto i test unitari per garantire che Frase si comporti correttamente quando interagisce con Word in base all'interfaccia di Word, scrivo il test di integrazione per assicurarmi che i miei presupposti sulle interazioni siano corretti. Per questo fornisco gli oggetti reali e scrivo un test che esercita una funzione che finirà per usare sia Frase che Parola.


43

I miei 10 bit: D

Mi è sempre stato detto che i test unitari sono i test di un singolo componente , che dovrebbe essere esercitato al massimo. Ora, questo tende ad avere molti livelli, poiché la maggior parte dei componenti sono fatti di parti più piccole. Per me, un'unità è una parte funzionale del sistema. Quindi deve fornire qualcosa di valore (cioè non un metodo per l'analisi delle stringhe, ma forse un HtmlSanitizer ).

Test di integrazione è il prossimo passo in avanti, ovvero prendere uno o più componenti e assicurarsi che funzionino insieme come dovrebbero. In questo modo si è al di sopra delle difficoltà di preoccuparsi del modo in cui i componenti funzionano individualmente, ma quando si immette html nel proprio HtmlEditControl , in qualche modo magicamente sa se è valido o no ..

È una vera linea mobile però ... Preferirei concentrarmi maggiormente sul far funzionare il dannato codice a tutto punto ^ _ ^


23

I test unitari usano beffe

La cosa di cui stai parlando sono i test di integrazione che testano effettivamente l'intera integrazione del tuo sistema. Ma quando si eseguono i test delle unità, è necessario testare ciascuna unità separatamente. Tutto il resto dovrebbe essere deriso. Quindi nel tuo caso di Sentenceclasse, se usa Wordclass, allora la tua Wordclasse dovrebbe essere derisa. In questo modo, testerai solo la Sentencefunzionalità della tua classe.


So che questo è un vecchio post, ma l'ho appena trovato. E se avessi una terza classe chiamata Font con cui interagisce la classe Frase e vuoi testare la funzionalità tra la classe Word e Frase, allora dovresti prendere in giro la classe Font ma questo non la renderà un test unitario. Quindi quello che sto dicendo è che l'uso di simulazioni non lo rende necessariamente un test unitario, le simulazioni possono essere utilizzate anche nei test di integrazione.
n.Stenvang,

2
Naturalmente mock possono essere utilizzati in test di integrazione, ma l'ordine per un test di unità siano effettivamente come tale tutto esterno alla unità deve essere simulato . Se i test di integrazione usano simulazioni, allora sono probabilmente test di integrazione parziali (se esiste un termine del genere). Esistono ovviamente test di integrazione parziali che sono top-down o bottom-up. Gli ultimi di solito non richiedono beffe mentre i primi lo fanno.
Robert Koritnik,

17

Penso che quando inizi a pensare ai test di integrazione, stai parlando più di un incrocio tra livelli fisici piuttosto che livelli logici.

Ad esempio, se i tuoi test si occupano della generazione di contenuti, è un test unitario: se il test riguarda se stesso con la sola scrittura su disco, è ancora un test unitario, ma una volta testato sia l'I / O che il contenuto del file, allora hai un test di integrazione. Quando si verifica l'output di una funzione all'interno di un servizio, si tratta di un test unitario, ma una volta effettuata una chiamata di servizio e verificato se il risultato della funzione è lo stesso, si tratta di un test di integrazione.

Tecnicamente, comunque, non è possibile effettuare unit test di una sola classe. Cosa succede se la tua classe è composta da diverse altre classi? Ciò lo rende automaticamente un test di integrazione? Io non la penso così.


8
"Tecnicamente, comunque, non puoi testare l'unità solo in una classe. E se la tua classe fosse composta da diverse altre classi?" Bene, un test unitario "rigoroso" deriderebbe / stub tutte le dipendenze. Tuttavia, è discutibile se questo sia sempre pratico ...
sleske,

2
Questo è vero sieske: l'importante è riuscire a mantenere le dipendenze al minimo.
Jon Limjap,

-1, un unit test non verifica una singola funzionalità, ma una singola funzione o classe software, ovvero verifica un'unità logica di software.
Charles B

12

usando il design a responsabilità singola, è in bianco e nero. Più di 1 responsabilità, è un test di integrazione.

Dal test delle anatre (sguardi, ciarlatani, ondeggianti, è un'anatra), è solo un test unitario con più di 1 oggetto nuovo.

Quando entri in mvc e lo collaudi, i test del controller sono sempre integrati, poiché il controller contiene sia un'unità modello che un'unità di visualizzazione. Test di logica in quel modello, chiamerei un unit test.


10

La natura dei tuoi test

Un test unitario del modulo X è un test che prevede (e verifica) i problemi solo nel modulo X.

Un test di integrazione di molti moduli è un test che prevede problemi che sorgono dalla cooperazione tra i moduli, pertanto questi problemi sarebbero difficili da trovare utilizzando i soli test unitari.

Pensa alla natura dei tuoi test nei seguenti termini:

  • Riduzione del rischio : ecco a cosa servono i test. Solo una combinazione di test unitari e test di integrazione può darti una riduzione completa del rischio, perché da un lato i test unitari non possono intrinsecamente testare la corretta interazione tra i moduli e, dall'altro lato, i test di integrazione possono esercitare la funzionalità di un solo modulo non banale in piccola parte.
  • Prova di scrittura : i test di integrazione possono risparmiare fatica perché potrebbe non essere necessario scrivere stub / falsi / beffe. Ma anche i test unitari possono risparmiare fatica quando si implementano (e si mantengono!) Quegli stub / falsi / beffe sembra essere più semplice della configurazione della configurazione di test senza di essi.
  • Ritardo dell'esecuzione del test : i test di integrazione che coinvolgono operazioni pesanti (come l'accesso a sistemi esterni come DB o server remoti) tendono ad essere lenti (er). Ciò significa che i test unitari possono essere eseguiti molto più frequentemente, il che riduce lo sforzo di debug in caso di problemi, perché nel frattempo hai un'idea migliore di cosa hai cambiato. Ciò diventa particolarmente importante se si utilizza lo sviluppo test-driven (TDD).
  • Sforzo di debug : se un test di integrazione fallisce, ma nessuno dei test unitari lo fa, questo può essere molto scomodo, perché c'è così tanto codice che potrebbe contenere il problema. Questo non è un grosso problema se in precedenza hai modificato solo poche righe, ma poiché i test di integrazione vengono eseguiti lentamente, forse non li hai eseguiti a intervalli così brevi ...

Ricorda che un test di integrazione può comunque eliminare / falsare / deridere alcune delle sue dipendenze. Ciò fornisce molta via di mezzo tra test unitari e test di sistema (i test di integrazione più completi, testando tutto il sistema).

Approccio pragmatico all'utilizzo di entrambi

Quindi un approccio pragmatico sarebbe: fare affidamento sui test di integrazione in modo flessibile, per quanto è possibile e utilizzare test unitari laddove ciò sia troppo rischioso o scomodo. Questo modo di pensare può essere più utile di una discriminazione dogmatica di unit test e test di integrazione.


10

Nel test unitario testate ogni parte isolata: inserisci qui la descrizione dell'immagine

nel test di integrazione test molti moduli del tuo sistema:

inserisci qui la descrizione dell'immagine

e questo succede quando si usano solo i test unitari (generalmente entrambe le finestre funzionano, purtroppo non insieme):

inserisci qui la descrizione dell'immagine

Fonti: source1 source2


Hai tre immagini ma solo due fonti.
Gerrit,

1
@gerrit dai un'occhiata alla prima fonte - due foto sono da lì
Michu93

1
Adoro questa risposta 👏
Dzenis H.

8

Secondo me la risposta è "Perché è importante?"

È perché i test unitari sono qualcosa che fai e i test di integrazione sono qualcosa che non fai? O vice versa? Certo che no, dovresti provare a fare entrambe le cose.

È perché i test unitari devono essere veloci, isolati, ripetibili, auto-validanti e tempestivi e i test di integrazione non dovrebbero? Certo che no, tutti i test dovrebbero essere questi.

È perché usi i mock nei test unitari ma non li usi nei test di integrazione? Ovviamente no. Ciò implicherebbe che se avessi un utile test di integrazione non potrei aggiungere una derisione per qualche parte, temendo che avrei dovuto rinominare il mio test in "unit test" o consegnarlo a un altro programmatore su cui lavorare.

È perché i test unitari testano un'unità e i test di integrazione testano un numero di unità? Ovviamente no. Di quale importanza pratica è? La discussione teorica sulla portata dei test si interrompe comunque nella pratica perché il termine "unità" dipende interamente dal contesto. A livello di classe, un'unità potrebbe essere un metodo. A livello di assieme, un'unità potrebbe essere una classe e, a livello di servizio, un'unità potrebbe essere un componente. E anche le classi usano altre classi, quindi qual è l'unità?

Non ha importanza.

Il test è importante, il PRIMO è importante, dividere i peli sulle definizioni è una perdita di tempo che confonde solo i nuovi arrivati ​​ai test.


5
-1 La definizione è ciò che rende le persone in grado di usare gli stessi termini senza spiegare sempre cosa significano ed è essenziale per la collaborazione. Pertanto è essenziale comprendere la differenza tra le due nozioni.
CharlesB,

Come accennato da @CharlesB è importante, quindi non c'è bisogno di spiegarlo ogni volta o di scoprire che ognuno ha una definizione diversa che causa confusione. I test verranno scritti in modo diverso e eseguiti in modo diverso, ma ciò non suggerisce che entrambi non dovrebbero essere eseguiti volendo definire le differenze.
Shane,

La conclusione della risposta può essere estrema, ma la maggior parte dei suoi punti sono abbastanza validi: i test unitari e i test di integrazione sono per lo più la stessa cosa tranne che per la loro granularità - e non è ovvio dove si debba tracciare una linea tra di loro.
Lutz Prechelt

Questo non aiuta quando si crea un linguaggio comune in un ambiente professionale. Anche se per lo più, hai ragione, non importa molto, non avere un linguaggio comune creerà incomprensioni e confusione tra la squadra. Penso che l'opzione migliore sia quella di far concordare al team i termini e le definizioni.
user924272,

4

Penso che chiamerei ancora un paio di classi interagenti un test unitario a condizione che i test unitari per class1 stiano testando le funzionalità di class1 e i test unitari per class2 stiano testando le sue funzionalità e anche che non stiano colpendo il database.

Chiamo un test un test di integrazione quando viene eseguito per la maggior parte del mio stack e raggiunge persino il database.

Mi piace davvero questa domanda, perché a volte la discussione su TDD mi sembra un po 'troppo purista ed è bello per me vedere alcuni esempi concreti.


4

Faccio lo stesso - li chiamo tutti test unitari, ma a un certo punto ho un "test unitario" che copre così tanto che spesso lo rinomino in "..IntegrationTest" - solo un cambio di nome, nient'altro cambia.

Penso che ci sia una continuazione dai "test atomici" (test di una piccola classe o un metodo) ai test unitari (a livello di classe) e ai test di integrazione - e quindi ai test funzionali (che normalmente coprono molte più cose dall'alto verso il basso) - non sembra esserci un taglio netto.

Se il tuo test imposta i dati e forse carica un database / file ecc., Forse è più un test di integrazione (i test di integrazione trovo che usano meno simulazioni e più classi reali, ma ciò non significa che non puoi deridere del sistema).


4

Unit Testing è un metodo di test che verifica che le singole unità del codice sorgente funzionino correttamente.

Il test di integrazione è la fase del test del software in cui i singoli moduli software vengono combinati e testati in gruppo.

Wikipedia definisce un'unità come la parte testabile più piccola di un'applicazione, che in Java / C # è un metodo. Ma nel tuo esempio di classe di parole e frasi probabilmente scriverei solo i test per la frase poiché probabilmente troverei eccessivo usare una classe di parole finta per testare la classe di frasi. Quindi la frase sarebbe la mia unità e la parola è un dettaglio di implementazione di quella unità.


4

Test di integrazione: viene verificata la persistenza del database.
Test unitari: l'accesso al database è deriso. I metodi di codice sono testati.


3

Il test dell'unità è il test contro un'unità di lavoro o un blocco di codice, se lo desideri. Solitamente eseguito da un singolo sviluppatore.

Il test di integrazione si riferisce al test eseguito, preferibilmente su un server di integrazione, quando uno sviluppatore commette il proprio codice in un repository di controllo del codice sorgente. I test di integrazione potrebbero essere eseguiti da utility come il Cruise Control.

Quindi fai i test delle tue unità per verificare che l'unità di lavoro che hai costruito funzioni e quindi il test di integrazione verifica che qualsiasi cosa tu abbia aggiunto al repository non abbia rotto qualcos'altro.


2

Chiamo unit test quei test che la scatola bianca verifica una classe. Eventuali dipendenze richieste dalla classe vengono sostituite con false (beffe).

I test di integrazione sono quei test in cui vengono testate più classi e le loro interazioni contemporaneamente. Solo alcune dipendenze in questi casi sono simulate / derise.

Non chiamerei i test di integrazione del controllore a meno che una delle loro dipendenze non sia vera (cioè non falsificata) (ad es. IFormsAuthentication).

Separare i due tipi di test è utile per testare il sistema a diversi livelli. Inoltre, i test di integrazione tendono a durare a lungo e i test unitari dovrebbero essere rapidi. La distinzione della velocità di esecuzione significa che sono eseguite in modo diverso. Nei nostri processi di sviluppo, i test unitari vengono eseguiti al check-in (il che va bene perché sono super veloci) e i test di integrazione vengono eseguiti una / due volte al giorno. Cerco di eseguire i test di integrazione il più spesso possibile, ma di solito colpisco il database / scrivo su file / rallentando rpc / etc.

Ciò solleva un altro punto importante, i test unitari dovrebbero evitare di colpire IO (es. Disco, rete, db). Altrimenti rallentano molto. Ci vuole un po 'di sforzo per progettare queste dipendenze IO - non posso ammettere di essere stato fedele alla regola "i test unitari devono essere veloci", ma se lo sei, i vantaggi su un sistema molto più grande diventano evidenti molto rapidamente .


2

Spiegazione semplice con analogie

Gli esempi sopra fanno molto bene e non ho bisogno di ripeterli. Quindi mi concentrerò sull'uso di esempi per aiutarti a capire.

Test di integrazione

I test di integrazione verificano se tutto funziona insieme. Immagina una serie di ingranaggi che lavorano insieme in un orologio. Un test di integrazione sarebbe: l'orologio indica l'ora corretta? Indica ancora l'ora corretta tra 3 giorni?

Tutto ciò che ti dice è se l'intero pezzo sta funzionando. Se fallisce: non ti dice esattamente dove sta fallendo.

Test unitari

Questi sono tipi di test davvero specifici. Ti dicono se una cosa specifica funziona o fallisce. La chiave di questo tipo di test è che verifica solo una cosa specifica mentre si presume che tutto il resto funzioni correttamente. Questo è il punto chiave.

Esempio: approfondiamo questo punto usando un esempio:

  • Prendiamo una macchina come esempio.
  • IntegrazioneTest di per un'auto: ad esempio l'auto guida a Woop Woop e ritorno? In tal caso, puoi tranquillamente affermare che un'auto funziona da un punto di vista generale. È un test di integrazione. Se fallisce non hai idea di dove stia effettivamente fallendo: è il radiatore, la trasmissione, il motore o il carburatore? Non avete idea. Potrebbe essere qualsiasi cosa.
  • Test unitario per un'auto: il motore funziona? Questo test presuppone che tutto il resto in macchina funzioni bene. In questo modo, se questo particolare test unitario fallisce: puoi essere molto sicuro che il problema risieda nel motore, quindi puoi isolarlo e risolverlo rapidamente.

Usando gli stub

  • Supponiamo che il test di integrazione dell'auto non abbia esito positivo. Non guida con successo su Echuca. Dov'è il problema?

  • Supponiamo ora che il tuo motore utilizzi uno speciale sistema di iniezione del carburante e che anche questo test dell'unità motore abbia fallito. In altre parole, sia il test di integrazione che il test dell'unità motore hanno avuto esito negativo. Dov'è allora il problema? (Concediti 10 secondi per ottenere la risposta.)

  • Il problema riguarda il motore o il sistema di iniezione del carburante?

Vedi il problema qui? Non sai cosa sta esattamente fallendo. Se usi dipendenze esterne diverse, ognuna di queste 10 potrebbe aver causato il problema e non saprai da dove iniziare. Ecco perché i test unitari utilizzano gli stub per supporre che tutto il resto funzioni correttamente.


1

Un po 'accademico questa domanda, no? ;-) Il mio punto di vista: per me un test di integrazione è il test dell'intera parte, non se due parti su dieci vanno insieme. Il nostro test di integrazione mostra se la build principale (contenente 40 progetti) avrà esito positivo. Per i progetti abbiamo tonnellate di unit test. La cosa più importante per quanto riguarda i test unitari è che un test unitario non deve dipendere da un altro test unitario. Quindi per me entrambi i test che descrivi sopra sono test unitari, se sono indipendenti. Per i test di integrazione questo non deve essere importante.


1

Questi test sono diventati essenzialmente test di integrazione perché ora testano l'integrazione di queste 2 classi? O è solo un test unitario che si estende su 2 classi?

Penso sì e sì. Il test unitario che si estende su 2 classi è diventato un test di integrazione.

Puoi evitarlo testando la classe Frase con un'implementazione simulata - Classe MockWord, che è importante quando quelle parti del sistema sono abbastanza grandi per essere implementate da sviluppatori diversi. In tal caso Word viene testato da solo unità, Frase viene testato da unità con l'aiuto di MockWord e quindi Frase viene testata per l'integrazione con Word.

L'esempio della vera differenza può essere il seguente: 1) Una matrice di 1.000.000 di elementi è facilmente testata dall'unità e funziona bene. 2) BubbleSort è facilmente testato in unità su una matrice simulata di 10 elementi e funziona anche bene 3) I test di integrazione mostrano che qualcosa non va così bene.

Se queste parti sono sviluppate da una sola persona, molto probabilmente si verificherà un problema durante il test di unità BubbleSoft solo perché lo sviluppatore ha già un array reale e non ha bisogno di un'implementazione fittizia.


1

Inoltre, è importante ricordare che sia i test unitari che i test di integrazione possono essere automatizzati e scritti utilizzando, ad esempio, JUnit. Nei test di integrazione di JUnit, è possibile utilizzare la org.junit.Assumeclasse per verificare la disponibilità di elementi di ambiente (ad esempio, connessione al database) o altre condizioni.


0

Se sei un purista TDD, scrivi i test prima di scrivere il codice di produzione. Naturalmente, i test non verranno compilati, quindi prima devi compilare i test, quindi far passare i test.

Puoi farlo con i test unitari, ma non con i test di integrazione o accettazione. Se avessi provato con un test di integrazione, nulla sarebbe mai compilato fino a quando non avessi finito!

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.