sql >> Base de Datos >  >> RDS >> PostgreSQL

Estadísticas de cobertura de código

Hace muchos años, Michelle Caise envió un parche para generar informes de cobertura de código para la base de código de PostgreSQL, basados ​​en la utilidad lcov. Aunque no puedo encontrar ningún registro de un parche real en los archivos de la lista de correo, Peter Eisentraut lo confirmó algún tiempo después y aplicó más mejoras más tarde.

Hoy estoy anunciando un nuevo servicio comunitario de PostgreSQL:informes de cobertura de código generados automáticamente y actualizados diariamente usando esta infraestructura. Este sistema compila la rama maestra, ejecuta make check-world y luego genera el informe HTML con hacer cobertura , que es lo que ves.

Informe de cobertura de código de muestra en src/backend/access/brin

Para los lectores que no estén familiarizados con la cobertura del código, un breve resumen:el código está "cubierto" cuando hay algún conjunto de pruebas que lo ejerce. El código que no está cubierto puede romperse fácilmente sin que nadie se dé cuenta, lo cual no es bueno. Para evitar la ruptura silenciosa del código, es importante que las pruebas cubran la mayoría de las líneas. Para una explicación más completa, aquí está la página de Wikipedia sobre el tema.

Históricamente, nuestras estadísticas en esta área han sido bastante malas; Si bien muchas funciones de back-end están bien cubiertas, hay varias funciones que solo están parcialmente cubiertas y otras que no están cubiertas en absoluto. Hemos ido mejorando en los últimos años; primero agregamos el probador de aislamiento, que nos permitió probar funciones que solo funcionan bajo concurrencia. En segundo lugar, añadimos pruebas TAP, que inicialmente iban a cubrir las utilidades del cliente, pero luego se ampliaron para cubrir también otras cosas, como el código de reproducción WAL y otras cosas. Pero está claro que aún nos queda un largo camino por recorrer.

Hay algunas advertencias a tener en cuenta. Una es que el make check-world el objetivo (sobre lo que informa esta herramienta de cobertura) no es lo que ejecuta buildfarm, por lo que es posible que los informes de cobertura estén ejecutando más pruebas que buildfarm, lo que significa que estamos reclamando cobertura sin tenerla realmente. Otra es que la cobertura se ejecuta en una sola plataforma (Debian en AMD64), por lo que el código para otras arquitecturas no se informa como cubierto.

¡Así que sal y explora! Quiero decir, explore el informe, descubra qué partes de nuestro código no están cubiertas e intente crear una prueba para solucionarlo. Esperamos con interés su parche en pgsql-hackers.

(Además:¿hay alguna prueba que debamos ejecutar que no sea make check-world ? Por favor, deje sus comentarios en los comentarios).