Come velocizziamo i test unitari?

Abbiamo raggiunto il punto nel nostro progetto in cui abbiamo quasi un migliaio di test e le persone hanno smesso di preoccuparsi di eseguirli prima di effettuare un check-in perché impiega così tanto tempo. Nella migliore delle ipotesi eseguono i test che sono rilevanti per il pezzo di codice che hanno cambiato e, nel peggiore dei casi, lo fanno semplicemente senza test.

Credo che questo problema sia dovuto al fatto che la soluzione è cresciuta fino a 120 progetti (di solito facciamo progetti molto più piccoli e questa è solo la seconda volta che facciamo TDD correttamente) e il tempo di build + test è aumentato a circa due-tre minuti sulle macchine minori.

Come ridurre il tempo di esecuzione dei test? Ci sono tecniche? Fingere di più? Fingere di meno? Forse i test di integrazione più grandi non dovrebbero essere eseguiti automaticamente quando si eseguono tutti i test?

Modifica: come risposta a molte delle risposte, usiamo già CI e un server di build, ecco come so che i test falliscono. Il problema (in realtà un sintomo) è che continuiamo a ricevere messaggi su build fallite. L'esecuzione di test parziali è qualcosa che la maggior parte delle persone fa ma non tutti. e per quanto riguarda i test, in realtà sono fatti abbastanza bene, usano falsi per tutto e non c'è alcun IO.

Una possibile soluzione sarebbe quella di spostare la parte di test dalle macchine di sviluppo a una configurazione di integrazione continua ( ad esempio Jenkins ) utilizzando un software di controllo della versione di qualche tipo ( git , svn , ecc ...).

Quando deve essere scritto un nuovo codice, lo sviluppatore specificato creerà un ramo per tutto ciò che sta facendo nel repository. Tutto il lavoro verrà svolto in questo ramo e possono eseguire il commit delle loro modifiche al ramo in qualsiasi momento senza incasinare la riga di codice principale.

Quando la funzione, la correzione di bug o qualsiasi altra cosa su cui stanno lavorando è stata completata, quel ramo può essere ricondotto nel trunk (o comunque preferisci farlo) dove vengono eseguiti tutti i test unitari. Se un test fallisce, l'unione viene rifiutata e lo sviluppatore viene avvisato in modo che possano correggere gli errori.

È inoltre possibile fare in modo che il proprio server CI esegua i test unitari su ciascun ramo delle funzioni quando vengono effettuati i commit. In questo modo lo sviluppatore può apportare alcune modifiche, eseguire il commit del codice e consentire al server di eseguire i test in background mentre continuano a lavorare su ulteriori modifiche o altri progetti.

Una grande guida per un modo di fare una tale configurazione può essere trovata qui (specifica per git ma dovrebbe funzionare per altri sistemi di controllo della versione): http://nvie.com/posts/a-successful-git-branching-model/

La maggior parte dei test unitari dovrebbe durare meno di 10 millisecondi circa. Avere 'quasi un migliaio di test' è nulla e dovrebbe prendere forse un paio di secondi per l'esecuzione.

Se non lo sono, allora dovresti smettere di scrivere test di integrazione altamente accoppiati (a meno che non sia quello di cui il codice ha bisogno) e iniziare a scrivere buoni test unitari (a partire da un codice ben disaccoppiato e dall'uso corretto di falsi / mock / stub / ecc.). Tale accoppiamento influirà sulla qualità del test e sul tempo necessario per scriverli, quindi non si tratta solo di ridurre il tempo di esecuzione del test.

Esistono diversi approcci che ho usato per risolvere un problema simile:

1. Controlla i tempi di esecuzione, trova tutti i test più lenti e poi analizza perché richiedono così tanto tempo per essere eseguiti .
2. Hai 100 progetti, potrebbe non essere necessario crearli e testarli ogni volta? Potresti correre tutto unittest solo in build notturne? Crea diverse configurazioni di build "veloci" per l'uso quotidiano . Il server CI eseguirà solo una serie limitata di progetti unittest relativi a parti "calde" del processo di sviluppo corrente .
3. Derida e isola tutto ciò che puoi , evita l'I / O su disco / rete ogni volta che è possibile
4. Quando non è possibile isolare tali operazioni, potresti avere dei test di integrazione? Potresti programmare test di integrazione solo per build notturne ?
5. Controllare tutti i singleton occasionali, che mantengono i riferimenti a istanze / risorse e che consumano memoria, ciò potrebbe causare il degrado delle prestazioni durante l'esecuzione di tutti i test.

Inoltre, puoi utilizzare i seguenti strumenti per semplificarti la vita e eseguire i test più velocemente

1. Gated commit alcuni server CI potrebbero essere configurati per eseguire build e test prima di eseguire il commit del codice nel repository di origine. Se qualcuno impegna il codice senza aver eseguito tutti i test in anticipo, che contiene anche test falliti, verrà rifiutato e restituito all'autore.
2. Configurare il server CI per eseguire test in parallelo : utilizzando più macchine o processi. Esempi sono pnunite la configurazione degli elementi della configurazione con diversi nodi.
3. Plug-in di test continuo per sviluppatori, che eseguirà automaticamente tutti i test durante la scrittura del codice.

0. Ascolta i tuoi programmatori.

Se non stanno eseguendo i test, significa che percepiscono che il costo (in attesa dell'esecuzione dei test, gestione di falsi fallimenti) sia maggiore del valore (cattura subito dei bug). Riduci i costi, aumenta il valore e le persone eseguiranno i test continuamente.

1. Rendi i tuoi test affidabili al 100%.

Se hai mai avuto test che falliscono con falsi negativi, affrontalo subito. Riparali, modificali, eliminali, qualunque cosa serva per garantire il 100% di affidabilità. (Va bene avere una serie di test inaffidabili, ma comunque utili che è possibile eseguire separatamente, ma il corpo principale dei test deve essere affidabile.)

2. Cambia i tuoi sistemi per garantire che tutti i test passino sempre.

Utilizzare sistemi di integrazione continua per garantire che solo i commit di passaggio vengano uniti al ramo principale / ufficiale / release / qualunque.

3. Cambia la tua cultura per valutare i test superati al 100%.

Insegnare alla lezione che un'attività non viene "eseguita" fino a quando non viene superato il 100% dei test ed è stata unita al ramo principale / ufficiale / release / qualunque.

4. Fai i test velocemente.

Ho lavorato su progetti in cui i test richiedono un secondo e su progetti in cui richiedono tutto il giorno. Esiste una forte correlazione tra il tempo necessario per eseguire i test e la mia produttività.

Più lunghi saranno i test da eseguire, meno spesso li eseguirai. Ciò significa che andrai più a lungo senza ricevere feedback sulle modifiche che stai apportando. Significa anche che passerai più tempo tra i commit. Commettere più spesso significa piccoli passi che sono più facili da unire; commettere la cronologia è più facile da seguire; trovare un bug nella storia è più facile; anche tornare indietro è più facile.

Immagina che i test vengano eseguiti così velocemente che non ti dispiace eseguirli automaticamente ogni volta che compili.

Effettuare i test velocemente può essere difficile (questo è quello che l'OP ha chiesto, giusto!). Il disaccoppiamento è la chiave. Falsi / falsi sono OK, ma penso che tu possa fare di meglio refactoring per rendere inutili i falsi / falsi. Vedi il blog di Arlo Belshee, a partire da http://arlobelshee.com/post/the-no-mocks-book .

5. Rendere utili i test.

Se i test non falliscono quando fallisci, qual è il punto? Insegnate a voi stessi a scrivere test che cattureranno i bug che probabilmente creerete. Questa è un'abilità a sé stante e richiederà molta attenzione.

Un paio di minuti è OK per i test unitari. Tuttavia, tieni presente che esistono 3 tipi principali di test:

1. Test unitari: testare ogni "unità" (classe o metodo) indipendentemente dal resto del progetto
2. Test di integrazione: verifica l'intero progetto, in genere effettuando chiamate nel programma. Alcuni progetti che ho visto combinano questo con i test di regressione. C'è molto meno derisione qui rispetto ai test unitari
3. Test di regressione: prova l'intero progetto completato, poiché la suite di test è un utente finale. Se si dispone di un'applicazione console, è possibile utilizzare la console per eseguire e testare il programma. Non esporre mai gli interni a questi test e qualsiasi utente finale del tuo programma dovrebbe (in teoria) essere in grado di eseguire la tua suite di test di regressione (anche se non lo faranno mai)

Questi sono elencati in ordine di velocità. I test unitari dovrebbero essere rapidi. Non cattureranno tutti i bug, ma stabiliranno che il programma è abbastanza sano. I test unitari dovrebbero essere eseguiti in 3 minuti o meno o hardware decente. Dici di avere solo 1000 test unitari e che durano 2-3 minuti? Bene, probabilmente va bene.

Cose da controllare:

• Assicurati però che i test unitari e i test di integrazione siano separati. I test di integrazione saranno sempre più lenti.

• Assicurarsi che i test unitari siano eseguiti in parallelo. Non c'è motivo per loro di non farlo se sono veri test unitari

• Assicurati che i test unitari siano "liberi da dipendenze". Non dovrebbero mai accedere a un database o al filesystem

A parte questo, i tuoi test non suonano troppo male in questo momento. Tuttavia, per riferimento, uno dei miei amici di un team Microsoft ha 4.000 test unit che vengono eseguiti in meno di 2 minuti su hardware decente (ed è un progetto complicato). È possibile effettuare test rapidi dell'unità. Eliminare le dipendenze (e deridere solo quanto necessario) è la cosa principale per ottenere velocità.

Addestra i tuoi sviluppatori su Personal Software Process (PSP) aiutandoli a capire e migliorare le loro prestazioni usando più disciplina. La scrittura del codice non ha nulla a che fare con lo sbattere le dita su una tastiera e successivamente premere un pulsante di compilazione e check-in.

PSP era molto popolare in passato quando la compilazione del codice era un processo che richiedeva molto tempo (ore / giorni su un mainframe, quindi tutti dovevano condividere il compilatore). Ma quando le stazioni di lavoro personali sono diventate più potenti, siamo arrivati ​​tutti ad accettare il processo:

1. digita un po 'di codice senza pensare
2. premi build / compilation
3. correggi la tua sintassi per farla compilare
4. esegui dei test per vedere se ciò che hai scritto ha davvero senso

Se pensi prima di digitare e, dopo aver digitato, rivedi ciò che hai scritto, puoi ridurre il numero di errori prima di eseguire una suite di build e test. Impara a non premere build 50 volte al giorno, ma forse una o due volte, quindi conta meno che il tempo di build e test richieda qualche minuto in più.

Un modo possibile: dividi la tua soluzione. Se una soluzione ha 100 progetti, è piuttosto ingestibile. Solo perché due progetti (diciamo A e B) usano un codice comune di un altro progetto (diciamo Lib) non significa che devono trovarsi nella stessa soluzione.

Invece, puoi creare la soluzione A con i progetti A e Lib e anche la soluzione B con i progetti B e Lib.

Sono in una situazione simile. Ho dei test unitari che testano la comunicazione con il server. Stanno testando il comportamento con timeout, annullando le connessioni ecc. L'intero set di test dura 7 minuti.

7 minuti è un tempo relativamente breve ma non è qualcosa che farai prima di ogni commit.

Abbiamo anche una serie di test automatici dell'interfaccia utente, il loro tempo di esecuzione è di 2 ore. Non è qualcosa che vuoi eseguire ogni giorno sul tuo computer.

Quindi che si fa?

1. La modifica dei test di solito non è molto efficace.
2. Esegui solo i test pertinenti prima del commit.
3. Esegui tutti i test ogni giorno (o più volte al giorno) su un server di build. Questo ti darà anche la possibilità di generare una buona copertura del codice e rapporti di analisi del codice.

L'importante è che tutti i test vengano eseguiti spesso perché è importante trovare i bug. Tuttavia, non è assolutamente necessario trovarli prima degli impegni.

Sebbene la tua descrizione del problema non fornisca una visione approfondita della base di codice, penso di poter tranquillamente affermare che il tuo problema è duplice.

Impara a scrivere i test giusti.

Dici di avere quasi mille test e di 120 progetti. Supponendo che al massimo metà di questi progetti siano progetti di test, sono disponibili 1000 test per 60 progetti di codice di produzione. Questo ti dà circa 16-17 test pr. progetto!!!

Questa è probabilmente la quantità di test che avrei dovuto coprire circa 1-2 classi in un sistema di produzione. Quindi, a meno che tu non abbia solo 1-2 classi in ciascun progetto (nel qual caso la struttura del tuo progetto è troppo fine) i tuoi test sono troppo grandi, coprono troppo terreno. Dici che questo è il primo progetto che stai facendo correttamente TDD. A dire il vero, i numeri che presenti indicano che non è così, non stai facendo la proprietà TDD.

Devi imparare a scrivere i test giusti, il che probabilmente significa che devi prima imparare a rendere testabile il codice. Se non riesci a trovare l'esperienza all'interno del team per farlo, ti suggerirei di assumere aiuto dall'esterno, ad esempio sotto forma di uno o due consulenti che aiutano il tuo team per una durata di 2-3 mesi a imparare a scrivere codice testabile, e piccoli test unitari minimi.

A titolo di confronto, sul progetto .NET su cui sto attualmente lavorando, possiamo eseguire circa 500 test unitari in meno di 10 secondi (e questo non è stato nemmeno misurato su una macchina con specifiche elevate). Se quelle fossero le tue figure, non avresti paura di gestirle localmente ogni tanto.

Impara a gestire la struttura del progetto.

Hai diviso la soluzione in 120 progetti. Questo è secondo i miei standard una quantità sbalorditiva di progetti.

Quindi, se ha senso avere effettivamente quella quantità di progetti (cosa che ho la sensazione che non abbia - ma la tua domanda non fornisce abbastanza informazioni per dare un giudizio qualificato su questo), devi dividere i progetti in componenti più piccoli che può essere compilato, versionato e distribuito separatamente. Pertanto, quando uno sviluppatore esegue l'unità della suite di test, deve solo eseguire i test relativi al componente su cui sta lavorando attualmente. Il server di compilazione dovrebbe occuparsi di verificare che tutto si integri correttamente.

Ma suddividere un progetto in più componenti compilati, sottoposti a versione e distribuiti separatamente richiede nella mia esperienza un team di sviluppo molto maturo, un team più maturo di quanto io abbia la sensazione che il tuo team sia.

Ma in ogni caso, devi fare qualcosa per la struttura del progetto. Dividi i progetti in componenti separati o inizia a unire i progetti.

Chiediti se hai davvero bisogno di 120 progetti?

ps Potresti voler dare un'occhiata a NCrunch. È un plug-in di Visual Studio che esegue automaticamente il test in background.

I test JUnit sono normalmente rapidi, ma alcuni di essi devono semplicemente impiegare del tempo per essere eseguiti.

Ad esempio, il test del database richiede in genere un po 'di tempo per inizializzare e terminare.

Se hai centinaia di test, anche se sono veloci, richiedono molto tempo per essere eseguiti a causa del loro numero.

Cosa si può fare è:

1) Identificare i test cruciali. Quelle per le parti più importanti delle biblioteche e quelle che hanno maggiori probabilità di fallire dopo le modifiche. Solo questi test devono essere eseguiti sempre in fase di compilazione. Se un codice viene spesso violato, i suoi test dovrebbero essere obbligatori anche se impiegano molto tempo per essere eseguiti, d'altra parte, se una parte del software non ha mai causato problemi, puoi saltare in sicurezza i test su ogni build.

2) Preparare il server di integrazione continua, che eseguirà tutti i test in background. Dipende da te se decidi di compilare ogni ora o di compilare dopo ogni commit (il secondo ha senso solo se vuoi rilevare automaticamente il cui commit ha causato problemi).

Problemi che ho visto:

a) Utilizzo del CIO per creare elementi di prova. 70 secondi -> 7 secondi rimuovendo il contenitore.

b) Non deridere tutte le classi. Mantieni i test unitari su un singolo elemento. Ho visto test che si diffondono in un paio di lezioni. Questi non sono test unitari e hanno molte più probabilità di rompersi.

c) Profilali per scoprire cosa stava succedendo. Ho scoperto che il costruttore stava costruendo cose di cui non avevo bisogno, quindi l'ho localizzato e ho ridotto i tempi di esecuzione.

d) Profilo. forse il codice non è così buono e puoi ottenere un po 'di efficienza da una recensione.

e) Rimuovere le dipendenze. Mantenere il test eseguibile piccolo ridurrà il tempo di caricamento. Utilizzare una libreria di interfaccia e contenitori IOC per eseguire la soluzione finale, ma i progetti di test principali dovrebbero avere solo la libreria di interfaccia definita. Ciò garantisce la separazione, assicura che sia più facile testare e riduce anche la stampa del piede di prova.

Sento il tuo dolore e mi sono imbattuto in diversi luoghi in cui la velocità di costruzione può essere migliorata molto. Tuttavia, il numero sulla cosa che consiglio è di misurare con un dettaglio granulare per capire dove la tua build sta impiegando più tempo. Ad esempio, ho una build con circa 30 progetti che richiede poco più di un minuto per l'esecuzione. Tuttavia, questa è solo una parte dell'immagine. So anche quali progetti impiegano più tempo per essere realizzati, il che aiuta a concentrare i miei sforzi.

Cose che consumano tempo di costruzione:

• Download del pacchetto (Nuget per C #, Maven per Java, Gem for Ruby, ecc.)
• Copia di grandi quantità di file sul file system (esempio: file di supporto GDAL)
• Apertura delle connessioni al database (alcune richiedono un secondo per connessione per la negoziazione)
• Codice basato sulla riflessione
• Codice generato automaticamente
• Utilizzo delle eccezioni per controllare il flusso del programma

Le librerie simulate usano la riflessione o iniettano codice usando le librerie bytecode per generare la simulazione per te. Sebbene sia molto conveniente, consuma tempo di prova. Se stai generando simulazioni all'interno di un loop nel tuo test, puoi aggiungere un tempo misurabile ai test unitari.

Esistono modi per risolvere i problemi:

• Spostare i test che coinvolgono un database all'integrazione (ovvero solo sul server di build CI)
• Evita di creare simulazioni nei loop nei tuoi test. In effetti, evita del tutto i loop nei tuoi test. Probabilmente puoi ottenere gli stessi risultati usando un test con parametri in quel caso.
• Valuta di dividere la tua soluzione di massa in soluzioni separate

Quando la tua soluzione contiene oltre 100 progetti, hai una combinazione di codice libreria, test e codice applicazione. Ciascuna delle librerie può essere la propria soluzione con i test associati. Jet Brains Team City è un server di build CI che funge anche da server Nuget - e sono sicuro che non è l'unico. Ciò ti dà la flessibilità di spostare quelle librerie che probabilmente non vengono cambiate spesso nelle proprie soluzioni / progetti e di utilizzare Nuget per risolvere le dipendenze per il codice dell'applicazione. Soluzioni più piccole significano che puoi apportare le modifiche a una libreria in modo rapido e semplice e goderti i vantaggi della soluzione principale.

Il tuo ambiente di test può essere eseguito ovunque? Se possibile, utilizzare il cloud computing per eseguire i test. Dividi i test tra N macchine virtuali. Se il tempo per eseguire i test su una singola macchina è T1 secondi, il tempo per eseguirli divisi, T2, potrebbe avvicinarsi a T2 = T1 / N. (Supponendo che ogni caso di test richieda la stessa quantità di tempo.) E devi pagare solo per le VM quando le stai usando. Quindi non hai un sacco di macchine di prova seduti in qualche laboratorio 24 ore su 24, 7 giorni su 7. (Mi piacerebbe poterlo fare dove lavoro, ma siamo legati a hardware specifico. Nessuna macchina virtuale per me.)