I revisori del codice dovrebbero testare come parte della revisione? [duplicare]

Una buona revisione del codice esaminerà il codice così com'è. Questo può essere difficile per lo sviluppatore che ha una buona comprensione di ciò che credono di aver scritto.

Ho coperto molte delle tue domande nella mia risposta trust-factor-in-code -una revisione. Mi aspetto che il codice in fase di revisione sia stato testato dallo sviluppatore. Ulteriori test dovrebbero essere coperti nelle varie suite di test. Mi dilungherò nell'esaminare un po 'questa è la tua domanda specifica.

Risponderei "No, il test non fa parte del processo di revisione del codice". Tuttavia, ci sono classi di errori che sono più facili da individuare nelle revisioni del codice rispetto ai test. Esistono anche tecniche di codifica che sono più soggette a errori che possono essere identificate nelle revisioni del codice. Ad esempio, una revisione del codice può identificare una denominazione delle variabili povera che è difficile da automatizzare.

Potrebbe essere appropriato rivedere i test unitari correlati. Le cose da cercare includono:

• Testano la funzionalità non banale?
• Provano l'importante funzionalità?
• Provano i casi limite importanti?
• Riesce a coprire ragionevolmente casi di successo?
• Rendono ragionevolmente i casi di fallimento?

Per qualsiasi codice non banale, non sarai in grado di coprire l'intero set di funzionalità in un ragionevole lasso di tempo. Tuttavia, i test unitari dovrebbero garantire che il codice sia funzionante e fallisca quando previsto.

Guarda il codice che implementa le funzionalità disponibili nelle librerie. Oltre ai casi di test, il codice della libreria viene pesantemente testato anche se utilizzato, e può avere importanti ottimizzazioni e controlli di sicurezza. In entrambi i casi, l'implementazione del tuo programmatore non verrà risolta quando la libreria lo fa. Se è necessario estendere la funzionalità della libreria, utilizzare un wrapper (sviluppato una sola volta per il progetto o l'organizzazione). Utilizza il più possibile la tecnologia "Non inventato qui".

Man mano che le revisioni generano una checklist di cose da elencare. Questo ti aiuterà a garantire che la revisione del codice sia buona come puoi fare.

Come identifichi i problemi, potresti voler produrre una lista di controllo dei problemi che le persone generano. Chiedi il loro elenco di errori comuni che fanno e usalo. Condividi la tua lista con loro e controlla il codice futuro da quello sviluppatore per quei problemi. Man mano che lo sviluppatore si sviluppa, i problemi che hanno cercato di evitare possono essere rimossi dalla loro lista.

Secondo me dipende da quanta copertura di test hanno le modifiche al codice e che tipo di test sta eseguendo il tuo team di QA. Durante la revisione, puoi vedere nel codice i vari input che vengono gestiti. Se i test coprono correttamente tutti questi input, penso che sarebbe una perdita di tempo per il revisore del codice per testarli manualmente. Tuttavia, se alcuni (o tutti) di questi input non sono coperti dai test, sarebbe prudente per il revisore del codice testare questi input, poiché il team di QA, che presumibilmente non ha accesso alla fonte, non li colpirà necessariamente casi nei loro test.

Nel caso in cui non ci sia praticamente alcuna copertura di test (ad esempio presso la mia attuale azienda), direi che è praticamente necessario che il revisore del codice esegua test funzionali.

Sono solidale con il fatto di avere pochissimi requisiti sulla revisione del codice. È anche mia comprensione, anche se non riesco a ricordare perché, la revisione del codice non strutturata non è affatto efficace. Il metodo Fagan di revisione del codice è una struttura molto stretta per la revisione del codice.

Detto questo, non vedo perché il test non dovrebbe essere una piccola parte della revisione del codice. Senza eseguire alcuni test, un revisore può solo avere un vago sospetto di ciò che è sbagliato in un pezzo di codice.

Quando il codice arriva a una revisione del codice, lo sviluppatore dovrebbe aver scritto test unitari, aver compilato con successo sia il codice sotto esame che i test unitari e aver passato tutti i test unitari attualmente scritti. Per questo motivo, il revisore del codice non dovrebbe dover testare il codice - l'autore del codice dovrebbe averlo già fatto. Se uno sviluppatore invia il codice per una revisione del codice che non esegue, compila o supera i test, questi dovrebbero essere ritenuti responsabili per sprecare il tempo di tutte le persone coinvolte nella revisione del codice.

Detto questo, potrebbe essere una buona idea esaminare anche i test unitari che corrispondono al codice in esame per assicurare che tutti i casi essenziali siano coperti, non ci sono casi di test estranei che rallenterebbero l'esecuzione del test e forse evidenzia altri casi che dovrebbero essere trattati se c'è tempo e / o risorse sufficienti. Migliorare la qualità dei test può solo migliorare la qualità generale del progetto.