sql >> Databasteknik >  >> RDS >> PostgreSQL

Kodtäckningsstatistik

För många år sedan skickade Michelle Caise in en patch för att generera kodtäckningsrapporter för PostgreSQL-kodbasen, baserat på LCOV-verktyget. Även om jag inte kan hitta några uppgifter om en faktisk patch i arkivet med e-postlistor, begick Peter Eisentraut det en tid senare och tillämpade ytterligare förbättringar senare.

Idag tillkännager jag en ny PostgreSQL-gemenskapstjänst:kodtäckningsrapporter genereras automatiskt och uppdateras dagligen med denna infrastruktur. Detta system kompilerar huvudgrenen, kör make check-world , och genererar sedan HTML-rapporten med make coverage , vilket är vad du ser.

Exempel på kodtäckningsrapport i src/backend/access/brin

För läsare som inte är bekanta med kodtäckning, en snabb sammanfattning:kod är "täckt" när det finns någon testsvit som utövar den. Kod som inte täcks kan lätt gå sönder utan att någon märker det, vilket inte är bra. För att undvika att kod bryts tyst är det viktigt att en majoritet av raderna täcks av tester. För en mer fullständig förklaring, här är Wikipedia-sidan om ämnet.

Vår statistik på detta område har historiskt sett varit ganska dålig; medan många backend-funktioner är väl täckta, finns det flera funktioner som bara täcks delvis, och andra som inte täcks alls. Vi har förbättrats de senaste åren; först lade vi till isolationstester, som gjorde det möjligt för oss att testa funktioner som bara fungerar samtidigt. För det andra lade vi till TAP-tester, som ursprungligen skulle täcka klientverktygen, men som senare utökades till att även omfatta andra saker som WAL-replay-koden och annat. Men det är klart att vi har en lång väg kvar än.

Det finns några varningar att tänka på. En är att make check-world target (vad det här täckningsverktyget rapporterar om) är inte vad buildfarmen kör, så det kan mycket väl vara så att täckningsrapporterna kör fler tester än buildfarm - vilket betyder att vi gör anspråk på täckning utan att faktiskt ha det. En annan är att täckning körs på en enda plattform (Debian på AMD64), så kod för andra arkitekturer rapporteras inte som täckt.

Så gå ut och utforska! Jag menar, utforska rapporten, ta reda på vilka delar av vår kod som inte täcks och försök skapa ett test för att fixa det. Vi väntar med intresse på din patch i pgsql-hackers.

(Även:finns det några tester som vi borde köra förutom make check-world ? Lämna feedback i kommentarerna).


  1. MySQL Ta bort dubbletter av poster

  2. Dataåtkomst från Raspberry Pi

  3. Hur Date()-funktionen fungerar i SQLite

  4. Hur man installerar MySQL på macOS