Come identificare ed eseguire i test automatici più rilevanti?

Esistono alcuni strumenti di analisi statica che possono aiutare a determinare "l'impatto del test", che può quindi eseguire i test effettuati.

Ma non posso fare a meno di pensare che stai risolvendo il sintomo, non il problema. Quando ho lavorato in QA, c'era un unico mantra che mi ha aiutato come sviluppatore: "non fidarti dello sviluppatore". Anche se potessi determinare "rilevante", non mi fiderei di avere ragione. Voglio dire che posso determinare che il mio codice è completo e corretto, perché ho bisogno di questo intero esercizio testing ?

Se i tuoi test sono troppo costosi, rendili meno costosi. È passato un decennio da quando ho usato un framework di test unitario a thread singolo. 500kloc dovrebbe impiegare (generosamente) 5-10 minuti per eseguire i test unitari. Esegui i test delle unità, prendi la maggior parte dei problemi e fornisci certezza sufficiente per controllare il codice.

I test di integrazione potrebbero richiedere più tempo a seconda del dominio. Non dovrebbero prendere così per tanto tempo che non puoi eseguirli durante la notte. Avere un intervallo di tempo tra il check-in ei test di integrazione che catturano i bug è abbastanza buono per la maggior parte degli ambienti, anche se ti incoraggerei comunque a velocizzare i test di integrazione isolandoli in particolari punti di integrazione, eliminando quelli che duplicano semplicemente l'unità test, o distribuendoli in una fattoria di prova.

La qualità è costosa. Risparmia la qualità e ottieni quello per cui paghi.

Se i test delle tue unità richiedono 6-7 ore, qualcosa non va. Dovrebbero richiedere alcuni minuti al massimo. Nota che dico dovrebbe - So quanto può essere difficile nella realtà. Forse è il momento di iniziare a prendere in giro i tuoi oggetti in modo da non dipendere dal filesystem o dal DB o qualsiasi altra cosa ti rallenti.

Non vuoi avere a che fare con l'elaborazione di quali test sono rilevanti o quali dovrebbero essere eseguiti continuamente - finirai per passare il tuo tempo a farlo invece di fare cose importanti, come fare le cose .

La selezione del test di regressione è il termine che stai cercando. Di recente ho iniziato a pensarci anch'io. Applicando i principi della compilazione incrementale, puoi determinare con certezza quali test devono essere eseguiti.

Utilizzando essenzialmente algoritmi già creati per la copertura del codice, è possibile creare un elenco di file dipendenti per ogni specifico test nella suite. Quindi, utilizzando il controllo della versione (o un elenco di hash del contenuto per ciascun file), puoi rilevare quali file sono stati modificati, quindi cercare il test da eseguire nel grafico delle dipendenze che hai creato.

Questo ovviamente ha dei problemi, come se i tuoi test si estendessero su più servizi diversi, il che rendeva più difficile la copertura del codice.

Ho appena pubblicato una domanda su reddit su questo argomento. Visualizza qui

TL; DR: crea un DAG dipendente dai moduli interessati

Identificare i test che sono influenzati da una particolare modifica equivale a identificare quando ricompilare / ricollegare un file oggetto. Creare un grafico aciclico diretto (DAG) dipendente dalla dipendenza dal modulo modificato. Dovresti essere in grado di attraversare tutte le importazioni per identificare ciò che deve essere testato. Puoi anche seguire da lì i test delle unità pertinenti. I test di integrazione saranno un po 'più difficili. È possibile eseguire il test di integrazione se si include il modulo aggiornato; oppure puoi provare a fare qualcosa di più intelligente come taggare le funzioni o gli oggetti che vengono richiamati durante i test e utilizzarli per determinare se è necessario eseguirli o meno.

Potresti prendere in considerazione solo l'esecuzione di test che hanno recentemente fallito. Dato che l'intero set richiede 6-7 ore (ovvero è eseguibile ogni notte), potresti basare i tuoi test sui risultati delle ultime notti. Se mischi alcuni test selezionati casualmente per una copertura più ampia nel corso della giornata, dovresti avere una buona possibilità di rilevare errori.

Questa idea è semplice da implementare, fa leva sulla nozione che la maggior parte dei test raramente, se mai fallisce (considerato un brutto segno nei test, ma di solito è difficile da prevenire). Puoi tenere quei test a basso valore per il tuo test notturno a copertura completa, ma eseguire i test più preziosi durante il giorno.

Se vuoi ottenere veramente di fantasia, puoi rinviare i test che sono correlati l'uno con l'altro, in particolare i test che falliscono solo quando alcuni altri test falliscono.