Test unità post mortem

Question

Controllo di versione con Git e test di unità con QUnit. A volte trovo un bug nel mio software che non era presente in una versione precedente. È facile per me scrivere un test unitario appositamente per quel bug.

Dato questo test di unità, posso facilmente passare attraverso tutti i miei passati commit e testare la build con quel test unitario, in modo da poter individuare quale commit ha causato la rottura?

Answer 1

Utilizzare git bisect per questo, vedere this page.

Poiché si sta testando JavaScript, probabilmente sarà necessario eseguire i test manualmente ed eseguire git bisect good e git bisect bad in base alle esigenze. Tuttavia, se è possibile eseguire il test di unità dalla riga di comando, quindi è possibile utilizzare git bisect run avere Git eseguire più volte la prova e rintracciare il guasto commit automaticamente:

$ git bisect run my-script.sh 

Questa è pura magia la prima volta che si vede ! :-)

Answer 2

Hai descritto il lavoro di git bisect. Il Git Book ha a good tutorial.

C'è anche una certa confusione nei termini della sua domanda: Quando si utilizza un test per difendersi reintroduzione di errori precedentemente fissati o per bisection di buggy impegna, si parla di un test di regressione, non un unit test. Quest'ultima prova è puramente testata se una determinata piccola unità di codice funziona, ed è soggetta a forti vincoli temporali (le persone del TDD eseguono test unitari diverse decine di volte in un giorno). Per un progetto di grandi dimensioni, di solito si hanno test di regressione molto più lunghi rispetto ai test unitari, quindi si potrebbe desiderare di ottenere le categorie pulite.

Answer 3

Sì, questo è chiamato git bisect ed è stato introdotto per la prima volta in git.

Principio:

• afferrare un commit in passato, quando si sa che ha funzionato, chiamiamolo c1;
• eseguire un commit dopo c1 in caso di errore, chiamare c2;
• git bisect start c2 c1.

Si può anche limitare la bisect per sottotracciati se si sa dove non riesce, e se si dispone di uno script in grado di eseguire il test di non interattivo, utilizzare git bisect run.

Answer 4

Git ha un comando per fare esattamente quello che vuoi, git bisect

Trova per ricerca binaria il cambiamento che ha introdotto un bug

Nel tuo caso si desidera utilizzare come git bisect run /path/to/script, che testerà automaticamente i commit ed eseguirà un controllo con ogni commit per trovare il commit errato.

Si noti che lo script (my_script nell'esempio precedente) deve uscire con il codice 0 se il codice sorgente corrente è buono e uscire con un codice compreso tra 1 e 127 (incluso), tranne 125, se l'origine corrente il codice è cattivo

Qualsiasi altro codice di uscita interromperà il processo di bisect. Va notato che un programma che termina con "exit (-1)" lascia $? = 255, (vedere la pagina di manuale dell'uscita (3)), poiché il valore viene tagliato con "& 0377".

Il codice di uscita speciale 125 deve essere utilizzato quando non è possibile testare il codice sorgente corrente. Se lo script termina con questo codice, la revisione corrente verrà saltata (vedi git bisect saltare sopra). 125 è stato scelto come il valore più alto da usare per questo scopo, perché 126 e 127 sono usati dalle shell POSIX per segnalare lo stato di errore specifico (127 è per comando non trovato, 126 è per comando trovato ma non eseguibile --- questi dettagli fanno non importa, in quanto sono errori normali nello script, per quanto riguarda "bisect run").

Quindi, lo script dovrebbe compilare le sorgenti, eseguire la suite di test dell'unità e quindi fornire il codice di uscita corrispondente. La sezione di esempio da bisect manpage copre questo bene (comprese le build rotte, l'unione di hotfix, ecc.)