sql >> Database >  >> RDS >> PostgreSQL

Code dekkingsstatistieken

Vele jaren geleden diende Michelle Caise een patch in om codedekkingsrapporten te genereren voor de PostgreSQL-codebasis, gebaseerd op het hulpprogramma LCOV. Hoewel ik in de archieven van de mailinglijst geen record van een daadwerkelijke patch kan vinden, heeft Peter Eisentraut deze enige tijd later gecommitteerd en later verdere verfijningen aangebracht.

Vandaag kondig ik een nieuwe PostgreSQL-communityservice aan:codedekkingsrapporten die automatisch worden gegenereerd en dagelijks worden bijgewerkt met behulp van deze infrastructuur. Dit systeem compileert de master branch, draait make check-world , en genereert vervolgens het HTML-rapport met make coverage , dat is wat je ziet.

Voorbeeldcodedekkingsrapport in src/backend/access/brin

Voor lezers die niet bekend zijn met codedekking, een korte samenvatting:code is "gedekt" wanneer er een testsuite is die deze uitoefent. Code die niet wordt gedekt, kan gemakkelijk worden verbroken zonder dat iemand het merkt, wat niet goed is. Om te voorkomen dat code stilzwijgend wordt verbroken, is het belangrijk dat de meeste regels worden getest. Voor een meer volledige uitleg, hier is de Wikipedia-pagina over dit onderwerp.

Onze statistieken op dit gebied zijn historisch gezien nogal slecht; hoewel veel backend-functies goed worden gedekt, zijn er verschillende functies die slechts gedeeltelijk worden gedekt en andere die helemaal niet worden gedekt. We zijn de afgelopen jaren aan het verbeteren; eerst hebben we de isolationtester toegevoegd, waarmee we functies konden testen die alleen onder gelijktijdigheid werken. Ten tweede hebben we TAP-tests toegevoegd, die aanvankelijk bedoeld waren om de hulpprogramma's van de client te dekken, maar later werden uitgebreid om ook andere dingen te dekken, zoals de WAL-replay-code en andere dingen. Maar het is duidelijk dat we nog een lange weg te gaan hebben.

Er zijn enkele kanttekeningen om in gedachten te houden. Een daarvan is dat de make check-world target (waar deze dekkingstool over rapporteert) is niet wat de buildfarm uitvoert, dus het kan zijn dat de dekkingsrapporten meer tests uitvoeren dan de buildfarm - wat betekent dat we dekking claimen zonder deze daadwerkelijk te hebben. Een andere is dat de dekking wordt uitgevoerd in een enkel platform (Debian op AMD64), dus code voor andere architecturen wordt niet gerapporteerd als gedekt.

Dus ga erop uit en ontdek! Ik bedoel, verken het rapport, zoek uit welke delen van onze code niet worden behandeld en probeer een test te maken om dat op te lossen. We wachten met belangstelling op uw patch in pgsql-hackers.

(Ook:zijn er andere tests die we zouden moeten uitvoeren dan make check-world ? Laat feedback achter in opmerkingen).


  1. Hoe groeipercentage van maand tot maand te berekenen in MySQL

  2. GO gebruiken binnen een transactie

  3. Oracle-query om kolomnamen op te halen

  4. MySQL en NoSQL:help me de juiste te kiezen