Il test di integrazione dovrebbe essere incluso nell'integrazione continua (CI)?

il nome continuo Integrazione dice molto. Quale posto migliore per fare test di integrazione rispetto a dove ti stai già integrando?
Ovviamente non dovrebbe essere l'unico posto in cui si svolgono questi test, quando si sviluppa dovresti cercare di assicurarti di non rompere le cose dopo tutto, non solo che le tue modifiche funzionino in modo isolato.
Alla fine, è responsabilità di ogni membro del team che le cose non si rompano, cercando di dare la colpa e definire rigidamente persone o stadi a cui i test sono limitati sono controproducenti.

Do you think if integration test should be included in continues integration (CI)?

Se hai dei test di integrazione che stanno passando e non chiedi a qualcuno di stare realmente lì e premi i pulsanti, allora sì - dovresti aggiungerli al sistema CI.

Tuttavia, poiché i test di integrazione possono richiedere molto tempo per essere eseguiti, è necessario limitare la frequenza con cui vengono eseguiti. Possono essere eseguiti durante una notte, quando il server CI è inattivo.

Per prima cosa rispondi alla tua domanda: Sì, fanno sicuramente parte dell'integrazione continua se me lo stai chiedendo. Ma penso che dobbiamo chiarire quali sono i test di integrazione.

Martin Fowler parlava della consegna continua come un modo per automatizzare il processo di compilazione completo da implementare rapidamente. Ciò richiede agli sviluppatori di ottenere un feedback rapido fornito dal processo di integrazione continua. Quindi definisce le fasi che la compilazione deve seguire :

1. a commit build
2. test completo
3. distribuzione

La build di commit non dovrebbe richiedere più di 10 minuti, afferma, a causa del rapido riscontro per gli sviluppatori.

Ecco come vedo le cose: Nel primo passaggio, recupera l'ultimo commit e lo crea. Se questo è successo, esegui i tuoi test unitari per scoprire se le tue classi / gruppi di classi funzionano come previsto e previsto.

Quando questo ha successo si arriva alla parte del test di integrazione. Qui testate l'interazione delle unità appena testate con successo. Ciò comporta l'alimentazione delle unità con input e la visualizzazione del loro stato / interazione / output. Ricorda che siamo ancora nella build di commit, quindi vogliamo che anche questo sia veloce. Pertanto, le interazioni con il file system, un database, i peer di rete e simili devono essere stub per un'esecuzione rapida. Martin Fowler suggerisce inoltre l'uso di database in-memory, se necessario, solo per mantenere l'esecuzione veloce sul server CI.

Dopo esserti assicurato che le unità funzionino e interagiscano come richiesto, di solito vuoi scoprire la copertura del test (solo testare un sottosistema di solito non è sufficiente) e rendere disponibili gli artefatti testati per test funzionali / QA / deployment (leggi: test approfonditi) se pensi di testare abbastanza cover del tuo programma. Proprio in quel momento, fornisci un ambiente di test che rispecchia l'ambiente di produzione a cui è destinato il targeting ed esegui test che coinvolgono un vero database, file reali, peer di rete reali, ecc.

Alla fine, i test di integrazione riguardano le modifiche al codice. Volete assicurarvi che le modifiche apportate non stiano rompendo il sistema attuale, il che significa che si integrano bene. Per scoprire se lo sono, è necessario assicurarsi che si comportino correttamente in se stessi, quindi se interagiscono correttamente con le loro dipendenze e se sono stati testati affatto. Puoi stare tranquillo sul tuo sistema dopo aver superato tutti quei test.

Se le fasi successive riscontrano problemi con il programma (come quando il database restituisce un certo valore, la connessione di rete si fermerà) dovresti provare a ottenere questi test eliminati nei test di integrazione. Molto probabilmente la build di commit è più veloce del QA;)