Che cos'è esattamente un test di integrazione?

Io e i miei amici abbiamo faticato a classificare esattamente cos'è un test di integrazione.

Ora, tornando a casa, mi sono appena reso conto che ogni volta che provo a dare un esempio reale di un test di integrazione, risulta essere un test di accettazione, vale a dire. qualcosa che un uomo d'affari direbbe ad alta voce che specifica cosa dovrebbe fornire il sistema.

Ho controllato la documentazione di Ruby on Rails per la loro classificazione di questi tipi di test, e ora mi ha lanciato completamente.

Potete darmi una breve descrizione accademica di un test di integrazione con un esempio del mondo reale?

Al momento mi piace questa affermazione: "Non è importante come la chiami, ma cosa fa" fatta da Gojko Adzic in questo articolo .

Devi davvero specificare con le persone che parlano dei test cosa intendi testare.

Ci sono molte persone che hanno opinioni diverse, a seconda del loro ruolo.

Per i tester una metodologia di prova generalmente accettata nei Paesi Bassi è TMap . TMap fa la seguente distinzione.

• unit test
• test di integrazione dell'unità
• test di sistema
• test di integrazione del sistema
• test di accettazione (tutti i tipi / livelli)
• test di accettazione funzionale
• test di accettazione dell'utente
• test di accettazione della produzione

Hanno tipi più specifici di test che possono essere eseguiti all'interno dei test sopra menzionati. Guarda questa parola doc per una panoramica.

Anche Wikipedia ha una bella panoramica .

Il libro del programmatore pragmatico dice:

• un unit test è un test che esercita un modulo
• i test di integrazione mostrano che le parti principali di un sistema funzionano bene insieme

Osservando queste diverse fonti e inserendo alcune delle mie esperienze e opinioni, inizierei facendo distinzioni per tre categorie

• chi fa i test in generale
• ciò che è testato

• qual è l'obiettivo del test

  • Unit test : testare la logica in classi da parte dei programmatori per mostrare la correttezza del livello di codice. Dovrebbero essere veloci e non dipendere da altre parti del sistema che non si intende testare
  • Test di accettazione funzionale : lo scenario del caso d'uso del test si basa su un set di dati limitato (appositamente creato) eseguito dal reparto test per dimostrare che ogni scenario specificato funziona come specificato.
  • Test di accettazione da parte dell'utente : testare scenari di casi d'uso sulla produzione come dati forniti da rappresentanti degli utenti per far sì che accettino formalmente l'applicazione
  • Test di integrazione : verifica i percorsi di comunicazione tra le diverse parti del modulo eseguite dal reparto test o dagli sviluppatori per dimostrare che tutti i moduli funzionano correttamente insieme.

La mia lista sopra è solo un inizio e un suggerimento, ma penso davvero: "Non è importante come lo chiami, ma cosa fa"

Spero che sia di aiuto.

26-10-2016 Modifica: Di recente è stata introdotta una bellissima introduzione ai test unitari di YouTube rispetto ai test di integrazione - MPJ's Musings - FunFunFunction # 55

test di integrazione, risulta essere un test di accettazione

Ovviamente.

Questi due sono quasi la stessa cosa. Ma ci sono alcune dimensioni leggermente diverse nella definizione del test.

Integrazione == l'intero sistema.

Accettazione == l'intero sistema.

L'unica differenza - e questo è sottile - è la definizione dei casi di test.

Integrazione == casi di test per verificare la profondità e il grado di integrazione. Funziona con tutti i casi limite e casi d'angolo? I casi di test tendono ad essere tecnici, scritti da designer e programmatori.

Accettazione == casi di test per esercitare solo l'80% incentrato sull'utente finale del set di funzionalità. Non tutti i casi limite e angolari. I casi di test tendono ad essere non tecnici, scritti dagli utenti finali.

Personalmente mi piace pensare a un test di integrazione come a un test di funzionalità quando ogni componente del sistema è reale , senza oggetti finti.

Un vero repository, un vero database, una vera interfaccia utente. Si verifica la funzionalità specifica quando il sistema è completamente assemblato ed è come dovrebbe essere quando distribuito.

Nella mia (ammetto) poca esperienza, ho capito che la parola integrazione può davvero creare fraintendimenti: davvero, è difficile trovare qualcosa di completamente isolato in un sistema, alcuni elementi avranno sicuramente bisogno di integrazione.

Pertanto, mi sono abituato a fare le seguenti distinzioni:

• Uso il test unitario per identificare, documentare e sottolineare tutti i comportamenti che la classe che sto testando è responsabile a realizzare.
• Sto facendo dei test di integrazione ogni volta che ho un componente (forse più di uno) nel mio sistema che sta conversando con un altro sistema " esterno ". (continua sotto ...)
• Implemento un test di accettazione per definire, documentare e sottolineare un certo flusso di lavoro previsto dal sistema.

Nella definizione del test di integrazione, per esterno intendevo un sistema che è fuori dal mio raggio di sviluppo : non posso cambiare immediatamente il modo in cui si comportano, per qualsiasi motivo. Potrebbe essere una libreria, un componente del sistema che non può essere modificato (ovvero è condiviso con altri progetti dell'azienda), un dbms, ecc. Per questi test ho bisogno di impostare qualcosa di molto simile all'ambiente reale del sistema funzionerà in: un sistema esterno deve essere inizializzato e impostato su un determinato stato; i dati realistici devono essere registrati nel db; eccetera.

Invece, quando faccio i test di accettazione, finto cose: sto lavorando a qualcosa di diverso, sto lavorando sulle specifiche del sistema, non sulla sua capacità di collaborare con entità esterne.

Questa è davvero una visione più ristretta rispetto a quanto descritto in precedenza da KeesDijk, tuttavia suppongo che i progetti a cui ho lavorato finora fossero abbastanza piccoli da permettermi questo livello di semplificazione.

Un test di integrazione verifica che i componenti di un sistema complesso (ad esempio software, aeromobili, centrali elettriche) funzionino insieme come previsto.

Immaginiamo di parlare di un aereo (con il software è più astratto e difficile fare la differenza). I test di integrazione comprendono, verificando:

• corretta interazione tra alcuni componenti. Esempio: premendo il pulsante di avvio, il motore si avvia e l'elica raggiunge la velocità di rotazione prevista (l'aeromobile rimane a terra)
• corretta interazione con componenti esterni. Esempio: verificare che la radio incorporata possa comunicare con una radio stazionaria (aeromobili ancora a terra)
• corretta interazione tra tutti i componenti coinvolti, in modo che il sistema nel suo complesso funzioni come previsto. Esempio: un equipaggio di piloti collaudatori e ingegneri avvia l'aereo e vola con esso (indossano tutti i paracadute ...).

Il test di integrazione risolve un problema tecnico , vale a dire che il sistema funziona nonostante la sua suddivisione in componenti. Nel software i componenti possono essere casi d'uso, moduli, funzioni, interfacce, librerie, ecc ...

Il test di collaudo verifica che il prodotto sia idoneo allo scopo. In linea di principio vengono eseguite dal cliente. Prendendo l'analogia dell'aeromobile, includono la verifica che:

• gli scenari di business previsti portano al risultato atteso in una situazione quasi reale. Esempio: provare un imbarco con passeggeri di prova per verificare che il personale possa monitorare l'imbarco come previsto con le procedure operative. Alcuni scenari potrebbero essere così semplici da sembrare un test unitario, ma vengono eseguiti dall'utente (ad es. Provare le prese elettriche con le apparecchiature dell'azienda).
• il sistema funziona in una situazione aziendale quasi reale. Esempio: effettuare un volo di prova vuoto tra due destinazioni reali, con piloti appena addestrati dalla compagnia aerea per verificare che il consumo di carburante sia come promesso.

Il test di accettazione affronta più un problema di responsabilità . In una relazione cliente / fornitore può essere una responsabilità contrattuale (conformità a tutti i requisiti). Ma in ogni caso è anche responsabilità dell'organizzazione utilizzatrice garantire che i propri compiti possano essere esercitati con il sistema e prevenire con prudenza qualsiasi problema imprevisto (ad esempio come questa società ferroviaria che durante i test di accettazione ha scoperto di dover accorciare alcuni quais perché i nuovi carri erano troppo grandi di 5 cm - nessuno scherzo!).

Conclusioni: i test di integrazione e accettazione si sovrappongono. Entrambi intendono dimostrare che il sistema nel suo insieme funziona. Tuttavia il "tutto" potrebbe essere più grande per il cliente (perché il sistema stesso può far parte di un sistema organizzativo più ampio) e più tecnico per l'integratore di sistema:

Il test di integrazione non è altro che il controllo della connessione e della correttezza del flusso di dati tra due o più moduli.

Ad esempio: quando componiamo una posta (un modulo) e la inviamo a un ID utente valido (secondo modulo), il test di integrazione è verificare se la posta inviata è presente negli articoli inviati.

Una definizione pratica di un test di integrazione è: qualsiasi test che richiede l'interazione con qualcosa di fuori processo.

Per esempio:

• Il file system
• Il network
• Un database
• Un'API esterna

Esiste un tipo di contratto tra il processo e il mondo esterno e la verifica minima che il contratto debba essere l'obiettivo di un test di integrazione. cioè non dovrebbe fare altro che verificare il contratto. In tal caso, ci si sposta verso lo spazio del sistema / end-to-end.

I test unitari sono in grado di testare tutta la logica entro il limite del processo e possono farlo facilmente proprio a causa della mancanza di dipendenze dal "mondo esterno" lento / fragile / complesso.

Mentre ci sono test di integrazione questa definizione non copre (quindi perché l'ho definita una definizione pratica ) penso che siano molto meno comuni / utili.

NB A rigor di termini, sì, questa definizione coprirebbe anche i test di sistema / end-to-end. Nella mia filosofia sono una forma di test di integrazione "estrema", quindi perché i loro nomi sottolineano un altro aspetto. Nella direzione opposta, un test unitario può essere considerato un test di integrazione di zero componenti, vale a dire che tutti i test possono essere considerati in qualche parte dello spettro di integrazione, integrando tra componenti 0-n :-)