Wiele lat temu Michelle Caise przesłała poprawkę do generowania raportów pokrycia kodu dla bazy kodu PostgreSQL, opartej na narzędziu lcov. Chociaż nie mogę znaleźć żadnego zapisu o rzeczywistej łacie w archiwach list dyskusyjnych, Peter Eisentraut zatwierdził ją jakiś czas później i zastosował dalsze poprawki później.
Dzisiaj zapowiadam nowy serwis społecznościowy PostgreSQL:raporty pokrycia kodu generowane automatycznie i aktualizowane codziennie przy użyciu tej infrastruktury. Ten system kompiluje gałąź master, uruchamia make check-world , a następnie generuje raport HTML z make pokrycia , czyli to, co widzisz.
Przykładowy raport pokrycia kodu w src/backend/access/brin
Dla czytelników niezaznajomionych z pokryciem kodu, krótkie podsumowanie:kod jest „pokryty”, gdy istnieje zestaw testów, który go sprawdza. Kod, który nie jest objęty, może łatwo zostać złamany bez zauważenia przez nikogo, co nie jest dobre. Aby uniknąć cichego łamania kodu, ważne jest, aby większość wierszy została objęta testami. Aby uzyskać pełniejsze wyjaśnienie, oto strona Wikipedii na ten temat.
Historycznie nasze statystyki w tej dziedzinie były raczej złe; podczas gdy wiele funkcji zaplecza jest dobrze omówionych, istnieje kilka funkcji, które są omówione tylko częściowo, a inne nie są w ogóle omówione. Poprawialiśmy się w ostatnich latach; najpierw dodaliśmy tester izolacji, który umożliwił nam testowanie funkcji, które działają tylko przy współbieżności. Po drugie dodaliśmy testy TAP, które początkowo miały objąć narzędzia klienta, ale później zostały rozszerzone o inne rzeczy, takie jak kod odtwarzania WAL i inne rzeczy. Ale jasne jest, że przed nami jeszcze długa droga.
Należy pamiętać o kilku zastrzeżeniach. Jednym z nich jest to, że stwórz świat kontroli cel (o czym raportuje to narzędzie pokrycia) nie jest tym, co działa buildfarm, więc może się zdarzyć, że raporty pokrycia przeprowadzają więcej testów niż buildfarm — co oznacza, że deklarujemy pokrycie, nie mając go w rzeczywistości. Innym jest to, że pokrycie działa na jednej platformie (Debian na AMD64), więc kod dla innych architektur nie jest zgłaszany jako objęty.
Więc wyjdź i odkrywaj! Mam na myśli, zapoznaj się z raportem, dowiedz się, które części naszego kodu nie są objęte, i spróbuj stworzyć test, aby to naprawić. Z zainteresowaniem czekamy na twoją łatkę w pgsql-hackers.
(Ponadto:czy są jakieś testy, które powinniśmy przeprowadzić, inne niż make check-world? ? Proszę zostawić opinię w komentarzach).
