Il y a de nombreuses années, Michelle Caise a soumis un correctif pour générer des rapports de couverture de code pour la base de code PostgreSQL, basée sur l'utilitaire lcov. Bien que je ne trouve aucun enregistrement d'un correctif réel dans les archives de la liste de diffusion, Peter Eisentraut l'a validé quelque temps plus tard et a appliqué d'autres améliorations plus tard.
Aujourd'hui, j'annonce un nouveau service communautaire PostgreSQL :des rapports de couverture de code générés automatiquement et mis à jour quotidiennement à l'aide de cette infrastructure. Ce système compile la branche master, exécute make check-world , puis génère le rapport HTML avec faire une couverture , c'est ce que vous voyez.
Exemple de rapport de couverture de code dans src/backend/access/brin
Pour les lecteurs peu familiarisés avec la couverture du code, un bref résumé :le code est « couvert » lorsqu'il existe une suite de tests qui l'exerce. Le code qui n'est pas couvert peut facilement être cassé sans que personne ne s'en aperçoive, ce qui n'est pas bon. Pour éviter de briser le code en silence, il est important qu'une majorité de lignes soient couvertes par des tests. Pour une explication plus complète, voici la page Wikipedia sur le sujet.
Nos statistiques dans ce domaine ont toujours été plutôt mauvaises; alors que de nombreuses fonctionnalités backend sont bien couvertes, il existe plusieurs fonctionnalités qui ne sont que partiellement couvertes et d'autres qui ne le sont pas du tout. Nous nous sommes améliorés ces dernières années; nous avons d'abord ajouté le isolationtester, qui nous a permis de tester des fonctionnalités qui ne fonctionnent qu'en simultanéité. Deuxièmement, nous avons ajouté des tests TAP, qui devaient initialement couvrir les utilitaires client, mais ont ensuite été étendus pour couvrir également d'autres choses telles que le code de relecture WAL et d'autres choses. Mais il est clair que nous avons encore un long chemin à parcourir.
Il y a quelques mises en garde à garder à l'esprit. La première est que le make check-world la cible (ce que cet outil de couverture rapporte) n'est pas ce que la buildfarm exécute, il se peut donc que les rapports de couverture exécutent plus de tests que la buildfarm - ce qui signifie que nous réclamons une couverture sans l'avoir réellement. Une autre est que la couverture est exécutée sur une seule plate-forme (Debian sur AMD64), donc le code pour d'autres architectures n'est pas signalé comme couvert.
Alors sortez et explorez ! Je veux dire, explorez le rapport, déterminez quelles parties de notre code ne sont pas couvertes et essayez de créer un test pour résoudre ce problème. Nous attendons votre patch dans pgsql-hackers avec intérêt.
(Aussi :y a-t-il des tests que nous devrions exécuter autres que make check-world ? Veuillez laisser des commentaires dans les commentaires).
