Che cos'è esattamente un test di integrazione?

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 test 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 utente
• test di accettazione della produzione

Hanno un tipo più specifico di test che possono essere eseguiti all'interno dei test sopra citati. Guarda questa parola doc per una panoramica.

Wikipedia ha anche una bella panoramica .

Il prenota il 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

Guardando queste diverse fonti e inserendo alcune mie esperienze e opinioni personali, vorrei iniziare distinguendo tre categorie

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

• qual è l'obiettivo del test

  • Test unità : verifica la logica nelle classi da parte dei programmatori per mostrare la correttezza del livello di codice. Dovrebbero essere veloci e non dipendenti da altre parti del sistema che non si intende testare
  • Test di accettazione funzionale : verifica lo scenario dei casi d'uso su un set di dati limitato (appositamente creato) eseguito dal reparto test per dimostrare che ogni scenario specificato funziona come specificato.
  • Test di accettazione degli utenti : verifica lo scenario dei casi d'uso sulla produzione come i dati fatti dai rappresentanti degli utenti per farli accettare 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 questo aiuti.

26-10-2016 Modifica: di recente è stata presentata un'introduzione molto bella su YouTube Test unitari e test di integrazione - MPJ Musings - FunFunFunction # 55

integration test, it turns out to be an acceptance test

Ovviamente.

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

Integrazione == il sistema nel suo complesso.

Accettazione == il sistema nel suo complesso.

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

Integrazione == casi di test per testare la profondità e il grado di integrazione. Funziona per tutti i casi limite e casi angolari? 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 angolare. I casi di test tendono ad essere non tecnici, scritti dagli utenti finali.

Personalmente mi piace pensare a un test di integrazione come feature test quando ogni componente del sistema è reale , nessun oggetto fittizio.

Un vero repository, un vero database, un'interfaccia utente reale. Metti alla prova funzionalità specifiche quando il sistema è completamente assemblato ed è come dovrebbe essere quando viene distribuito.

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

Così mi sono abituato a fare le seguenti distinzioni:

• Io uso unit test per identificare, documentare e sottolineare tutti i comportamenti la classe che sto testando è responsabile realizzare.
• Sto facendo test di integrazione ogni volta che ho un componente (forse più di uno) nel mio sistema che è avendo qualche conversazione con un altro Sistema " esterno ". (continua qui di seguito ...)
• Implemento un test di accettazione per definire, documentare e sottolineare un certo flusso di lavoro che è previsto dal sistema.

Nella definizione del test di integrazione, per esterno intendevo il sistema fuori dal mio intervallo 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 (cioè condiviso con altri progetti in 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; dati realistici devono essere registrati nel db; ecc.

Invece, quando sto facendo test di accettazione ho falso cose: sto lavorando su qualcosa di diverso, sto lavorando sulle specifiche del sistema, non sulla sua capacità di collaborare con esterni entità.

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

Un test di integrazione verifica che i componenti di un sistema complesso (ad es. software, aeromobili, centrale elettrica) funzionino insieme come progettato.

Immaginiamo di parlare di un aereo (con il software è più astratto e difficile da 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'aereo rimane ancora a terra)
• corretta interazione con componenti esterni. Esempio: verificare che la radio incorporata possa comunicare con una radio stazionaria (aereo 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 e ingegneri collaudatori avvia l'aereo e vola con esso (tutti indossano paracadute ...).

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

Il test di accettazione verifica che il prodotto sia adatto allo scopo. In linea di massima vengono eseguiti dal cliente. Prendendo l'analogia dell'aereo, includono la verifica che:

• gli scenari di business previsti portano al risultato atteso in una situazione quasi reale. Esempio: provare un imbarco con i passeggeri del test 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 esempio, 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 di nuova formazione della compagnia aerea per verificare che il consumo di carburante sia come promesso.

Il test di accettazione risolve 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 che li utilizza assicurare che i loro compiti possano essere portati avanti con il sistema e prevenire prudentemente qualsiasi problema imprevisto (es. Come questa società ferroviaria che scoprì durante i test di accettazione che dovevano accorciare alcuni quais perché i nuovi carri erano 5 cm troppo grandi - nessuna battuta!).

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

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

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

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

Ad esempio:

• Il file system
• La rete
• Un database
• Un'API esterna

Esiste un contratto di sorta tra il tuo processo e il mondo esterno, e la verifica minima del contratto dovrebbe essere l'obiettivo di un test di integrazione. cioè non dovrebbe fare altro che verificare il contratto. Se lo fa, ti stai spostando verso il sistema / lo spazio end-to-end.

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

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

NB. A rigor di termini, sì, questa definizione coprirà anche i test di sistema / end-to-end. Nella mia filosofia sono una forma di test di integrazione "estremo", quindi perché i loro nomi enfatizzano un altro aspetto. Nell'altra direzione, un test unitario può essere considerato un test di integrazione di componenti zero, cioè Tutti i test possono essere considerati da qualche parte nello spettro di integrazione, integrando tra componenti 0-n :-)