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

Supponiamo che stiamo sviluppando un'applicazione Web e Hudson svolge lavori tipici come compilazione, unit test e analisi di codice statico.

Ma la parte difficile è: Hudson distribuisce e avvia il server delle applicazioni per eseguire test di integrazione , una volta eseguiti i lavori precedenti.

Ciò significa che alcune cose difficili, come la connessione al database, la connessione all'applicazione di terze parti, l'ascolto della porta socket, le variabili di ambiente, la gestione degli errori di avvio del server, ecc. Dobbiamo impostare e demolire queste cose correttamente ogni volta, è una cosa difficile. Peggio ancora, i test di integrazione possono interrompere facilmente il test di integrazione.

Pensi che se il test di integrazione debba essere incluso nella continuazione dell'integrazione (CI)? Può essere manualmente? O semplificare il test di integrazione?

il nome Integrazione continua dice molto. Quale posto migliore per eseguire i test di integrazione rispetto a dove ti stai già integrando?
Ovviamente non dovrebbe essere l'unico posto in cui si svolgono questi test, durante lo sviluppo dovresti cercare di assicurarti di non rompere le cose dopo tutto, non solo che i tuoi cambiamenti funzionino da soli.
Alla fine, è responsabilità di ogni membro del team che le cose non si rompano, cercando di dare la colpa e definire rigidamente le persone o le fasi a cui i test sono limitati sono controproducenti.

Pensi che se il test di integrazione debba essere incluso nella continuazione dell'integrazione (CI)?

Se hai dei test di integrazione che stanno superando e non hai bisogno di qualcuno che si trovi effettivamente lì e premi i pulsanti, allora sì: dovresti aggiungerli al sistema CI.

Tuttavia, poiché l'esecuzione dei test di integrazione può richiedere molto tempo, è necessario limitare la frequenza con cui vengono eseguiti. Possono essere eseguiti durante la notte, quando il server CI è inattivo.

Per prima cosa rispondere 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 stava parlando della consegna continua come un modo per automatizzare l'intero processo di compilazione da implementare rapidamente. Ciò richiede agli sviluppatori di ottenere un rapido feedback fornito dal processo di integrazione continua. Quindi definisce le fasi che la build dovrebbe attraversare :

1. una build di commit
2. test approfonditi
3. distribuzione

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

Ecco come vedo le cose: nel primo passaggio, recupera l'ultimo commit e crealo. Se questo ha esito positivo, esegui i test unitari per scoprire se le tue classi / gruppi di classi funzionano come definito e previsto.

Quando questo ha esito positivo, si arriva alla parte del test di integrazione. Qui si verifica l'interazione delle unità appena testate con successo. Ciò implica alimentare le unità con input e guardare il loro stato / interazione / output. Ricorda che siamo ancora nella build di commit, quindi vogliamo che anche questo sia veloce. Quindi le interazioni con il file system, un database, i peer di rete e simili devono essere eliminate per una rapida esecuzione. Martin Fowler suggerisce anche l'uso di database in memoria se necessari, solo per mantenere veloce l'esecuzione sul server CI.

Dopo esserti assicurato che le unità funzionino e interagiscano come richiesto, di solito vuoi scoprire la copertura dei test (solo testare un piccolo sottosistema di solito non è abbastanza) e rendere disponibili gli artefatti testati per test funzionali / QA / implementazione ( leggi: test approfonditi) se ritieni che i test coprano abbastanza del tuo programma. Proprio in quel momento, si esegue il provisioning di un ambiente di test che rispecchia l'ambiente di produzione di destinazione e si eseguono test che coinvolgono un database reale, file reali, peer di rete reali, ecc.

Alla fine, i test di integrazione riguardano le modifiche al codice. Vuoi assicurarti che le modifiche apportate non stiano rompendo il sistema attuale, nel senso 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. Puoi stare tranquillo con il tuo sistema dopo aver superato tutti questi test.

Se le fasi successive riscontrano problemi con il programma (come quando il database restituisce un determinato valore, la connessione di rete si interromperà), è necessario provare a superare questi test nei test di integrazione. La build di commit molto probabilmente è più veloce del QA;)