Caratteristiche, Differenza e Similitudine tra Code review e Testing software

Code review e Testing software

Molti team, oltre ai modelli di testing, utilizzano la pratica della code review, cioè del “controllo del codice”. Di seguito andremo a definire vantaggi, svantaggi, analogie e differenze di entrambi gli approcci.

La code review è una tecnica che permette di analizzare il codice alla ricerca di errori, codice non pulito o non elegante, mancanze dal punto di vista della sicurezza o codice troppo complesso. Lo scopo è principalmente assicurare la qualità del codice garantendo allo stesso tempo che faccia ciò che dovrebbe. La review inoltre è fatta da uno o più membri del team diversi da chi ha scritto il codice.

D’altro canto, il testing normalmente ha come unico focus quello di scovare gli errori ed eventualmente di servire da documentazione, in modo che sia più chiaro cosa una parte di codice fa, o cosa dovrebbe fare.

Mentre, la revisione del codice ha vari vantaggi, primo fra tutti il fatto che lo stesso viene osservato da un’altra persona e quindi da un altro punto di vista, in secondo luogo i revisori possono far notare incongruenze tra il codice prodotto e il resto della code base (metodi con lo stesso nome, riferimenti a classi non più esistenti etc.) dando quindi una più vasta visone d’insieme. In aggiunta, se si utilizzano sia le pratiche di testing che quelle di review, queste ultime permettono di controllare la correttezza e la completezza dei test. Un altro vantaggio sta nell’apprendimento, infatti i reviewer, trovando codice non pulito, suggeriranno una maniera per migliorarlo, condividendo la loro idea con gli altri e portando ad aumento delle expertise di tutto il team.

Questa descrizione pùo portare a pensare che le review possano sostituire totalmente il testing, ciò invece è sconsigliato, in quanto porta a vari svantaggi che dettaglieremo di seguito. La revisione è un processo manuale e come tale è soggetto a molti errori umani e necessita di tempo, inoltre nessun reviewer sarà mai certo che un pezzo di codice non introduca side-effect o che non rompa del codice scritto in passato. In aggiunta, va specificato che il compito diventa sempre più difficile con l’aumento della quantità di codice del progetto, tanto che il push di commit in produzione (senza regression tests) si rivela molto pericoloso.

Tuttavia neanche il testing rimpiazza le code review, innanzitutto perchè i test non guardano alla qualità del codice, ma anche perchè il controllo di uno sviluppatore esperto pùo scovare errori difficilmente riscontrabili tramite le suite. Per esempio, un reviewer potrebbe accorgersi di bug che si manifestano solo durante i weekend e cioè quando i test automatici non vengono eseguiti (ad esempio errata indicizzazione di un array) oppure di errori che si producono solo con un preciso numero di utenti (ad esempio cattiva gestione di un caso limite).
In conclusione sia la code review che il testing hanno molti vantaggi e limiti, per cui non bisogna considerarle pratiche mutualmente esclusive, infatti molto spesso, nei team di successo, vengono utilizzate entrambe.

 

Testare i test software

Infine, nell’ambito del testing software, un problema non banale è verificare che i test facciano ciò che devono, per validarli esistono più strategie tra cui:

1. Simulare manualmente tutti i possibili casi che il test pùo incontrare per verificare che dia sempre la risposta corretta;
2. Costruire un test automatico che verifichi il comportamento dei test;
3. Effettuare delle code review sul codice di test.

Solo il primo caso dà la certezza del funzionamento dei test, ma è virtualmente impossibile da effettuare. Nel secondo metodo il problema si ripresenta ricorsivamente, e quindi quest’ultimo non rappresenta una soluzione definitiva. La terza modalità è solitamente la più utilizzata, poichè più semplice delle altre, però, per essere veramente efficace, il codice da verificare deve essere molto pulito e chiaro, in modo da evitare incomprensioni.