Muitos anos atrás, Michelle Caise enviou um patch para gerar relatórios de cobertura de código para a base de código PostgreSQL, com base no utilitário lcov. Embora eu não consiga encontrar nenhum registro de um patch real nos arquivos da lista de discussão, Peter Eisentraut o comprometeu algum tempo depois e aplicou mais refinamentos posteriormente.

Hoje estou anunciando um novo serviço comunitário do PostgreSQL:relatórios de cobertura de código gerados automaticamente e atualizados diariamente usando essa infraestrutura. Este sistema compila o branch master, executa make check-world e gera o relatório HTML com make cobertura , que é o que você vê.

Exemplo de relatório de cobertura de código em src/backend/access/brin

Para leitores não familiarizados com a cobertura de código, um resumo rápido:o código é “coberto” quando há algum conjunto de testes que o exercita. O código que não é coberto pode facilmente ser quebrado sem que ninguém perceba, o que não é bom. Para evitar a quebra de código silenciosamente, é importante que a maioria das linhas seja coberta por testes. Para uma explicação mais completa, aqui está a página da Wikipedia sobre o assunto.

Nossas estatísticas nesta área têm sido historicamente muito ruins; enquanto muitos recursos de back-end são bem cobertos, existem vários recursos que são apenas parcialmente cobertos e outros que não são cobertos. Temos melhorado nos últimos anos; primeiro adicionamos o teste de isolamento, que nos permitiu testar recursos que operam apenas em simultaneidade. Em segundo lugar, adicionamos os testes TAP, que inicialmente deveriam cobrir os utilitários do cliente, mas depois foram estendidos para cobrir também outras coisas, como o código de repetição WAL e outras coisas. Mas é claro que ainda temos um longo caminho a percorrer.

Há algumas ressalvas a serem lembradas. Uma é que o make check-world target (sobre o que esta ferramenta de cobertura relata) não é o que o buildfarm executa, então pode ser que os relatórios de cobertura estejam executando mais testes do que o buildfarm – o que significa que estamos reivindicando cobertura sem realmente tê-la. Outra é que a cobertura é executada em uma única plataforma (Debian no AMD64), portanto, o código para outras arquiteturas não é relatado como coberto.

Então saia e explore! Quero dizer, explore o relatório, descubra quais partes do nosso código não são cobertas e tente criar um teste para corrigir isso. Aguardamos seu patch no pgsql-hackers com interesse.

(Também:existem testes que devemos executar além de make check-world ? Por favor, deixe comentários nos comentários).