La revisione del codice deve essere eseguita prima o dopo i test unitari

Sto discutendo con il mio collega su quando eseguire la revisione del codice - prima o dopo i test unitari. Qual è la migliore pratica?

Alcuni fattori che potremmo dover tenere in considerazione (potrebbero essercene altri):

• Dimensione della modifica del codice: una grande modifica implica che ulteriori modifiche deriveranno dalla revisione del codice. Se queste modifiche sono maggiori di, se UT era prima della revisione del codice, dovrai ripetere nuovamente la maggior parte delle UT.
• Tempo richiesto per eseguire il test unitario
• È una nuova funzionalità o una correzione di bug

Dovresti sempre provare l'unità prima di fare la revisione del codice ed ecco perché

1. Se il tuo codice viene infranto in modo tale da essere catturato dai test unitari, sprecherai il tempo dell'altro sviluppatore coinvolgendolo nel ciclo rosso / verde / refactor.
2. I test mostrano ad altri sviluppatori l'uso previsto del codice che semplifica la revisione.
3. I test devono essere esaminati insieme al codice testato nel caso in cui manchino casi di test o i test non funzionino correttamente.
4. I test e la revisione del codice tendono a rilevare diversi problemi con solo una piccola sovrapposizione nei problemi rilevati. I test unitari non si infastidiscono nel dover ripetere il test del codice quando il revisore rileva problemi, gli sviluppatori si infastidiscono e probabilmente non lo faranno la seconda volta.

Probabilmente ci sono altri motivi, ma quelli sono quelli che ho visto e sperimentato personalmente avendo implementato pratiche di revisione del codice all'interno di 3 diversi team / aziende.

Modifica Naturalmente quanto sopra è per i momenti in cui la revisione del codice è un passo nel processo di sviluppo del software (sia a cascata che agile). Se stai lavorando su una sezione di codice particolarmente grande o difficile, sentiti libero di avere un altro paio di occhi su di esso in qualsiasi momento.

Le recensioni del codice servono per quando il codice è "fatto".

Nella mia organizzazione la nostra definizione di "fatto" include i test unitari (come puntiamo a TDD), quindi le revisioni del codice sono di codice completo e il codice completo include i test.

Inoltre, i test necessitano di revisione e refactoring, quindi ha senso che facciano parte della revisione del codice.

I test devono essere considerati parte del codice da rivedere. Pertanto ha senso rivedere dopo aver eseguito i test.

Assicurati che anche i test vengano rivisti. Questo è fondamentale per coloro che non conoscono i test unitari.

Assicurati che il tuo team sottoponga a iniezione di dipendenza, quadri di isolamento, simulazioni vs tronconi, cuciture, test di interazione vs stato e test di integrazione vs unità.

Non è necessario implementare gli argomenti di cui sopra, ma è necessario capirli.

Bene,

Questo dipende da cosa intendi per "Unit Test" ...

Se si trattava di un Unit Test in stile TDD, non ha senso perché si scrive test mentre si scrive il codice. Non esiste un caso successivo. In questo caso si migliora continuamente la qualità del codice: Refactoring ...

E

Se fosse un classico "test unitario" [qualunque cosa significhi non lo so, ma intendo test dopo aver scritto i codici e fatto di solito da altri ragazzi] allora i criteri principali sono quello che ti aspetti da codereview e dalla natura dei test unitari: se vuoi un rapido feedback, fai una revisione e agisci e non hai un unit test automatico, dovrai aspettare unit test. Se si desidera identificare problemi maturi con la revisione del codice e applicare in modo incrementale la soluzione per le iterazioni successive, è possibile farlo prima del test unitario ...

Ma dopo tutto personalmente, per codereview, dopo o dopo il test unitario non è un vero criterio per me ...

Perché facciamo codereview? Per la qualità del codice ... Invece di un gate di "controllo qualità", inserisci la qualità nel tuo ambiente di processo di sviluppo software ...

Tenderei a dire, siamo "agili" ... non aspettare che il codice sia finito per fare una rapida revisione informale del codice: ci sono sviluppatori con cui e soggetti con cui puoi davvero aspettare l'intero codice + fase di test da terminare ... ma

quando si tratta di argomenti davvero nuovi (funzionalità completamente nuova, quasi ricerca, qualcosa di totalmente nuovo per il team), revisione del codice in anticipo, non perdere tempo: chiedi a un collega di dare un'occhiata di tanto in tanto: l'isolamento è un fattore importante di fallimento in questo caso.

se lo sviluppatore è nuovo per il team, rivedere il codice in anticipo e forse spesso .

e, a proposito, anche i test unitari richiedono una revisione del codice.