Che cos’è e a cosa serve la piattaforma Codecov nel testing software

White-box Testing

Nell’ambito del testing software, i test di tipo white-box, ovvero “a scatola bianca” devono il loro nome al fatto di essere basati sulla struttura interna o sull’implementazione del sistema, che può includere codice, architettura, flussi di lavoro o flussi di dati all’interno del sistema.

Un primo vantaggio del collaudo a scatola bianca è che permette di sondare dettagliatamente tutte le casistiche che possono presentarsi, e lo fa in modo facile ed efficiente grazie all’automazione.

Un altro è la semplificazione del debugging, cioè il passaggio dal malfunzionamento alla correzione del difetto, in quanto la segnalazione del bug normalmente indica il punto del codice e i valori delle variabili per cui questo si è manifestato.

Le tecniche di testing strutturale hanno in genere l’obiettivo di coprire quanto più codice possibile, andando ad analizzare tutte le istruzioni, procedure e porzioni di codice che compongono la struttura del programma. Generalmente l’obiettivo è quello di raggiungere un’ampia coverage, quindi di coprire più codice possibile. Per fare ciò è necessario definire un insieme di test, e di conseguenza una serie di dati di input, per fare in modo che tutte le componenti del sistema, e quindi tutte le sue funzionalità, siano coperte almeno una volta dall’esecuzione dei test.

Che cos’è la Code coverage

La code coverage (in italiano copertura di codice) è una metrica che permette di verificare la percentuale del codice che è stata testata, ovvero il numero di righe di codice che viene eseguito mentre i test girano. Utilizzando degli strumenti opportuni, come in questo caso Jest, è possibile anche sapere con esattezza quali sono le parti che non sono ancora state testate, cosi da integrare la nostra suite di test con quelli mancanti. Nello specifico ci sono 4 parametri che la code coverage prende in considerazione:

Statements: indica la percentuale di statements eseguiti.
Branches: indica la percentuale di path intrapresi.
Functions: indica la percentuale di funzioni testate.
Lines: indica la percentuale di righe di codice eseguite tramite i test.

Il 100% di Statement Coverage assicura che tutte le dichiarazioni eseguibili nel codice siano state testate almeno una volta, ma non garantisce che sia stata testata tutta la logica decisionale. Quando si raggiunge invece il 100% di Decision Coverage, si eseguono tutti i risultati delle decisioni (branches), che includono sia il caso dell’esito positivo (true) che di quello negativo (false), anche quando non c’è un’esplicita dichiarazione falsa (nel caso di un if senza il corrispondente else). Questo tipo di coverage aiuta a trovare difetti nel codice che altri test non sono in grado di garantire. Il raggiungimento del 100% di questo tipo di coverage garantisce anche la copertura totale della Statement coverage (ma non viceversa).

In ogni caso, la code coverage è una buona misura della quantità di codice testato, ma non è affatto indicativa per quanto riguarda la qualità dei test, per quello sono richiesti altri strumenti che non verranno approfonditi in questo paragrafo.

Per rendere disponibile il report online, è necessario ricorrere ad un ulteriore piattaforma, Codecov, che riesce ad accedere al repository originale.

Che cos’è la piattaforma Codecov

La piattaforma Codecov utilizza 3 termini per descrivere una linea di codice che è stata eseguita:

hit: indica che il codice è stato eseguito dalla suite di test,
partial: indica che il codice è stato parzialmente eseguito, ma ci sono dei branch che non sono stati testati,
miss: indica che il codice non è stato eseguito dalla suite di test.

Il rapporto su cui si basa Codecov è hits/(hits + partial + miss). Questo tipo di strumenti incoraggiano gli sviluppatori a scrivere test e ad aumentare la code coverage. Durante il processo di scrittura dei test, lo sviluppatore potrebbe scoprire nuovi bug o problemi di sintassi nel codice sorgente che sono importanti da risolvere prima di rilasciare l’applicazione. Codecov, a differenza dei prodotti open source e a pagamento, si concentra sull’integrazione e sulla promozione di pull request corrette. Integra le metriche direttamente nel flusso di lavoro per promuovere una maggiore copertura del codice, in particolare nelle richieste pull in cui si verificano comunemente nuove funzionalità e correzioni di bug.