L'integrazione continua con i test è utile per assicurarsi che il codice "shippable" sia controllato in ogni momento.

Tuttavia, è davvero difficile mantenere una serie completa di test e spesso, sembra che la build sarà comunque buggy.

Quanti test dovresti avere fiducia nei test della tua pipeline CI? Usi una sorta di metrica per decidere quando ci sono abbastanza test?

In generale

Quando hai abbastanza test automatici per avere fiducia nella tua pipeline di integrazione continua?

La risposta probabilmente diventa chiara se pensi a ciò di cui vuoi essere sicuro. In definitiva, mappa 1-1; ogni test ti rende sicuro dell'unica cosa che verifica:

• Il test unitario ti dà la certezza che una classe (o un modulo) fa ciò per cui è stata testata.
• Il test di integrazione ti dà la certezza che diverse unità lavorano insieme nel modo in cui è testato.
• I test end-to-end ti danno la certezza che l'intera applicazione fa una certa cosa, come descritto nel test.

Dal modo in cui hai formulato la tua domanda, probabilmente stai pensando in un senso generale in questo momento, ad esempio:

Voglio essere sicuro che la mia applicazione può fare X .

Quindi scrivi un test end-to-end che prova a fare X e controlla se lo fa correttamente.

Più concreto

È tutto autoreferenziale, ma è perché è quello a cui si riduce. Semplicemente non c'è altro.

Ad esempio, immagina di scrivere un'app per creare ricette di cucina. Una caratteristica è che, se aggiungi diverse quantità di diversi tipi di formaggio, ti dà la temperatura e il tempo corretti in modo che si sciolgano tutti.

Quindi puoi scrivere un test unitario per il tuo CheeseMeltCalculator, dove gli dai 100 g di Gouda e 200 g di formaggio Emmental, e poi controlli che la temperatura e il tempo siano corretti. Ciò significa che ora puoi essere sicuro che CheeseMeltCalculatorfunziona con 100 g di Gouda e 200 g di formaggio. Ora, se ripeti questo test con 300 g di Gouda anziché 200 g, puoi essere abbastanza sicuro che funzioni correttamente per valori diversi. È possibile aggiungere test per 0, -1e int.MaxValueg di Gouda essere sicuri che il codice non inciampare (o viaggi correttamente come previsto) per l'ingresso strano.

È possibile scrivere un test di integrazione per verificare che CheeseMeltCalculatorsia incorporato correttamente nell'intero processo di calcolo della temperatura e del tempo degli alimenti. Se il problema persiste, ma i CheeseMeltCalculatortest sopra riportati sono soddisfacenti, si può essere certi che il bug si trova in altri calcolatori o nel modo in cui vengono combinati i dati di diversi calcolatori.

E infine puoi scrivere un test end-to-end per creare un'intera ricetta, e una delle cose che controlli è la temperatura e il tempo del risultato. Se i precedenti 2 livelli di test vanno bene, ma per questo va storto, allora puoi essere di nuovo sicuro che quelle parti siano corrette e l'errore è qualcosa su come il calcolo della temperatura è integrato nell'applicazione. Ad esempio, forse l'input dell'utente non è stato trasferito correttamente.

E infine , se tutti questi test vanno bene, allora puoi essere sicuro che " se aggiungi quantità diverse di diversi tipi di formaggio, ti dà la temperatura e il tempo corretti in modo che si sciolgano tutti "

Per farla breve

Il punto è che non puoi avere un test "funziona correttamente". Puoi solo provare "Se faccio X, succede Y".

Tuttavia, questo è esattamente ciò che dovrebbe essere nelle specifiche tecniche per il progetto. Un'affermazione come " se aggiungi diverse quantità di diversi tipi di formaggio, ti dà la temperatura e il tempo corretti in modo che si sciolgano tutti " non solo dà al cliente chiare aspettative su ciò che farà il prodotto finito, ma può anche essere trasformato in test automatizzati.

informazioni addizionali

L'utente Richard ha aggiunto queste informazioni in una modifica:

Martin Fowler ha un bellissimo riassunto sul suo sito web sulle strategie più comuni: https://martinfowler.com/articles/microservice-testing/

Non voglio rimuovere questo, ma voglio dire questo: rispetto a questa risposta, non è un "riassunto", ma piuttosto una spiegazione molto più approfondita, con una bella grafica e tutto il resto.

Il mio consiglio sarebbe: se tutto ha senso per te dopo aver letto la mia risposta, hai finito. Se le cose sembrano ancora poco chiare, dedica un po 'di tempo e leggi l'articolo collegato.

Non esiste una metrica che puoi calcolare che ti darà la fiducia che stai cercando. La fiducia si costruisce facendo qualcosa, e poi riuscendoci o fallendo e imparando qualcosa da essa.

L'unica "metrica" ​​che ho trovato che mi dà fiducia nella nostra copertura di test è:

1. Numero di difetti riscontrati nella produzione
2. È possibile effettuare il refactoring della base di codice e fare affidamento sulla copertura del test per rilevare difetti di regressione?

I test automatici non sono un proiettile d'argento. È necessario tenere traccia di quanti difetti di produzione vengono rilevati durante ciascun ciclo di rilascio. Quando questo numero diminuisce, stai offrendo un software migliore. Test automatici e integrazione continua sono solo strumenti che usi per fornire un software migliore.

L'unica metrica che puoi davvero misurare è "Stai offrendo software migliore?"

E anche allora, è soggettivo.

Quando hai abbastanza test automatici per avere fiducia nella tua pipeline di integrazione continua?

Nella maggior parte del contesto economico non avrai il budget per implementare abbastanza fiducia (> 99%) ma dovrai gestire un budget limitato: si tratta solo del rapporto costi / benefici.

• Alcuni test automatici sono economici da implementare, alcuni sono estremamente costosi.
• A seconda dell'effettiva gestione del rischio, alcuni rischi devono essere coperti da prove mentre altri no.

Quindi in realtà i test facili / economici / rischiosi saranno implementati mentre i test costosi / improbabili no.

Uno degli obiettivi secondari dello sviluppo di software è quello di creare un'architettura così facile / economica da testare (progettare per la testabilità applicando Test-driven_development ) per mantenere accessibili i test automatizzati.

Presumo che il Pareto_principle possa essere applicato anche per software gestibile / testabile qui: dice che spendendo il 20% in più di denaro si ottiene l'80% di vantaggio in più. Per ottenere il restante 20% di vantaggio in più, è necessario spendere un ulteriore 80% di denaro.

È possibile applicare le metriche di prova come la copertura del codice e la copertura delle mutazioni per mostrare il proprio codice sorgente non testato.

Ma anche con una copertura del 100% non puoi essere certo che il tuo codice sia privo di bug.

La gestione ama la codemetria. Se la "copertura del codice> = 80%" viene applicata dalla direzione mentre gli sviluppatori non supportano / come i test automatizzati, ci sono modi per scrivere testcode con copertura elevata che non provano nulla che dia un falso senso di sicurezza.

Il trucco qui non è quello di preoccuparsi della copertura completa ma nella gestione del rischio delle modifiche.

Supponiamo che tu stia utilizzando la pipeline per distribuire esattamente la stessa versione di già in Produzione: qual è il rischio di errore di regressione? Zero (perché non ci sono cambiamenti).

Ora, diciamo che voglio cambiare un pezzo di testo su uno degli schermi. Ho aggiunto il test per verificare che il testo sia ora visualizzato correttamente (supponiamo per amor di argomenti che sia un pezzo di testo DAVVERO importante). Di quali altri test ho bisogno per verificare che non ci siano errori di regressione? Realisticamente nessuno ...

Pertanto, il numero di test automatizzati richiesti per la pubblicazione di ciascuna versione non dipende dalle dimensioni dell'applicazione, ma dalle dimensioni della modifica. Se stai apportando piccole modifiche a basso rischio, avrai bisogno di molti meno test per mitigare i rischi.

Ma aspetta un minuto ... questo non si allinea molto bene con il punto di CI e CD?

Sì! Mantenendo tutte le modifiche e i delta molto piccoli, stai mitigando molti dei rischi di regressione attraverso il processo anziché i test. Inoltre, la domanda in realtà non diventa di automazione (questo è solo lo strumento che useremo) - è semplicemente una questione di test e propensione al rischio. Dimentica completamente l'automazione, quali test eseguiresti contro una modifica per assicurarti che una modifica non abbia introdotto problemi? La risposta a questa domanda non cambia da un processo di test manuale a un sistema di CI: l'unico vantaggio è che molti di quei test di regressione potrebbero essere stati precedentemente sviluppati con funzionalità precedenti e CI ti incoraggia a apportare modifiche più piccole e più sicure.

TLDR

I tuoi test mirano a mitigare il rischio del cambiamento. Una distribuzione con un delta pari a zero non ha alcun rischio e pertanto non comporta alcun rischio. Mantenendo piccole le modifiche diventa molto più semplice identificare i test necessari per convalidarli: la riusabilità dell'automazione è un vantaggio.

È la stessa metrica di quando si esegue il test manuale del prodotto.

In pratica, è facile identificare queste zone a bassa confidenza: supponendo che stai spedendo il prodotto, suppongo che tu abbia alcuni passaggi manuali post-pipeline che migliorano la tua sicurezza di essere spedibile. Queste sono le aree che dovresti automatizzare per migliorare la fiducia nel processo automatico stesso.

La tua automazione è uno sforzo continuo. Cresce e migliora man mano che il tuo prodotto migliora. Un difetto è un motivo per ripensare il codice, oltre a ripensare l'elemento della configurazione. E il lato positivo qui è che, poiché la fiducia nel prodotto stesso è realizzabile, anche la fiducia nell'automazione è raggiungibile.