PostgreSQL
 sql >> Database >  >> RDS >> PostgreSQL

Statistiche sulla copertura del codice

Molti anni fa, Michelle Caise ha presentato una patch per generare report di copertura del codice per la base di codice PostgreSQL, basata sull'utilità lcov. Sebbene non riesca a trovare alcuna registrazione di una patch effettiva negli archivi della mailing list, Peter Eisentraut l'ha impegnata qualche tempo dopo e ha applicato ulteriori perfezionamenti in seguito.

Oggi annuncio un nuovo servizio della community di PostgreSQL:report di copertura del codice generati automaticamente e aggiornati quotidianamente utilizzando questa infrastruttura. Questo sistema compila il ramo principale, esegue make check-world , quindi genera il report HTML con make coverage , che è quello che vedi.

Esempio di report di copertura del codice in src/backend/access/brin

Per i lettori che non hanno familiarità con la copertura del codice, un breve riassunto:il codice è "coperto" quando c'è una suite di test che lo esercita. Il codice non coperto può essere facilmente violato senza che nessuno se ne accorga, il che non va bene. Per evitare la rottura silenziosa del codice, è importante che la maggior parte delle righe sia coperta da test. Per una spiegazione più completa, ecco la pagina di Wikipedia sull'argomento.

Le nostre statistiche in quest'area sono state storicamente piuttosto pessime; mentre molte funzionalità di back-end sono ben coperte, ci sono diverse funzionalità che sono solo parzialmente coperte e altre che non sono affatto coperte. Stiamo migliorando negli ultimi anni; per prima cosa abbiamo aggiunto l'isolationtester, che ci ha permesso di testare funzionalità che funzionano solo in simultanea. In secondo luogo abbiamo aggiunto i test TAP, che inizialmente dovevano coprire le utilità del client, ma sono stati successivamente estesi per coprire anche altre cose come il codice di riproduzione WAL e altre cose. Ma è chiaro che abbiamo ancora molta strada da fare.

Ci sono alcuni avvertimenti da tenere a mente. Uno è che il mondo make check target (quello di cui questo strumento di copertura riporta) non è ciò che viene eseguito dalla buildfarm, quindi potrebbe benissimo essere che i report di copertura stiano eseguendo più test rispetto alla buildfarm, il che significa che stiamo rivendicando la copertura senza effettivamente averla. Un altro è che la copertura viene eseguita su un'unica piattaforma (Debian su AMD64), quindi il codice per altre architetture non viene segnalato come coperto.

Quindi esci ed esplora! Voglio dire, esplora il rapporto, scopri quali parti del nostro codice non sono coperte e prova a creare un test per risolverlo. Attendiamo con interesse la tua patch in pgsql-hacker.

(Inoltre:ci sono dei test che dovremmo eseguire oltre a make check-world ? Si prega di lasciare un feedback nei commenti).