Vor vielen Jahren reichte Michelle Caise einen Patch ein, um Codeabdeckungsberichte für die PostgreSQL-Codebasis basierend auf dem Dienstprogramm lcov zu generieren. Obwohl ich in den Archiven der Mailingliste keinen Hinweis auf einen aktuellen Patch finden kann, hat Peter Eisentraut ihn einige Zeit später übernommen und später weitere Verfeinerungen vorgenommen.
Heute kündige ich einen neuen PostgreSQL-Community-Service an:Berichte zur Codeabdeckung, die mithilfe dieser Infrastruktur automatisch generiert und täglich aktualisiert werden. Dieses System kompiliert den Hauptzweig und führt make check-world aus , und generiert dann den HTML-Bericht mit Abdeckung erstellen , was Sie sehen.
Beispielbericht zur Codeabdeckung in src/backend/access/brin
Für Leser, die mit Codeabdeckung nicht vertraut sind, eine kurze Zusammenfassung:Code ist „abgedeckt“, wenn es eine Testsuite gibt, die ihn ausführt. Code, der nicht abgedeckt ist, kann leicht beschädigt werden, ohne dass es jemand merkt, was nicht gut ist. Um zu vermeiden, dass Code unbemerkt unterbrochen wird, ist es wichtig, dass eine Mehrheit der Zeilen von Tests abgedeckt wird. Eine vollständigere Erklärung finden Sie hier auf der Wikipedia-Seite zu diesem Thema.
Unsere Statistiken in diesem Bereich waren historisch eher schlecht; Während viele Backend-Funktionen gut abgedeckt sind, gibt es einige Funktionen, die nur teilweise abgedeckt sind, und andere, die überhaupt nicht abgedeckt sind. Wir haben uns in den letzten Jahren verbessert; Zuerst haben wir den Isolationstester hinzugefügt, der es uns ermöglichte, Funktionen zu testen, die nur unter Parallelität funktionieren. Zweitens haben wir TAP-Tests hinzugefügt, die ursprünglich die Client-Dienstprogramme abdecken sollten, aber später erweitert wurden, um auch andere Dinge wie den WAL-Wiedergabecode und andere Dinge abzudecken. Aber es ist klar, dass wir noch einen langen Weg vor uns haben.
Es gibt einige Vorbehalte zu beachten. Eine davon ist die make check-world target (worüber dieses Coverage-Tool berichtet) ist nicht das, was die Buildfarm ausführt, daher kann es gut sein, dass die Coverage-Berichte mehr Tests ausführen als die Buildfarm – was bedeutet, dass wir die Abdeckung beanspruchen, ohne sie tatsächlich zu haben. Ein weiterer Grund ist, dass die Abdeckung auf einer einzelnen Plattform ausgeführt wird (Debian auf AMD64), sodass Code für andere Architekturen nicht als abgedeckt gemeldet wird.
Also geh raus und erkunde! Ich meine, untersuchen Sie den Bericht, finden Sie heraus, welche Teile unseres Codes nicht abgedeckt sind, und versuchen Sie, einen Test zu erstellen, um das zu beheben. Wir erwarten mit Interesse Ihren Patch in pgsql-hackers.
(Außerdem:Gibt es irgendwelche Tests, die wir außer make check-world ausführen sollten ? Bitte hinterlassen Sie Feedback in den Kommentaren).
