PostgreSQL
 sql >> база данни >  >> RDS >> PostgreSQL

Статистика за покритието на кода

Преди много години Мишел Кейз представи пач за генериране на отчети за покритието на кода за кодовата база на PostgreSQL, базирана на помощната програма lcov. Въпреки че не мога да намеря никакъв запис на действителна корекция в архивите на пощенския списък, Питър Айзентраут го направи известно време по-късно и приложи допълнителни уточнения по-късно.

Днес обявявам нова обществена услуга на PostgreSQL:отчети за покритието на кода, генерирани автоматично и актуализирани ежедневно с помощта на тази инфраструктура. Тази система компилира главния клон, изпълнява make check-world , и след това генерира HTML отчета с направи покритие , което виждате.

Примерен отчет за покритието на кода в src/backend/access/brin

За читатели, които не са запознати с покритието на кода, кратко обобщение:кодът е „покрит“, когато има някакъв тестов пакет, който го упражнява. Код, който не е покрит, може лесно да бъде разбит, без никой да забележи, което не е добре. За да избегнете безшумното прекъсване на кода, важно е повечето редове да бъдат покрити от тестове. За по-пълно обяснение, ето страницата на Wikipedia по темата.

Статистиките ни в тази област исторически са били доста лоши; докато много функции на бекенда са добре покрити, има няколко функции, които са покрити само частично, а други, които изобщо не са покрити. Подобрихме се през последните години; първо добавихме isolationtester, който ни позволи да тестваме функции, които работят само при паралелност. Второ, добавихме TAP тестове, които първоначално трябваше да покрият помощните програми на клиента, но по-късно бяха разширени, за да обхванат и други неща като кода за възпроизвеждане на WAL и други неща. Но е ясно, че имаме още дълъг път.

Има някои предупреждения, които трябва да имате предвид. Единият е, че make check-world target (за което отчита този инструмент за покритие) не е това, което buildfarm управлява, така че може да се окаже, че отчетите за покритие изпълняват повече тестове от buildfarm - което означава, че ние претендираме за покритие, без всъщност да го имаме. Друго е, че покритието се изпълнява в една платформа (Debian на AMD64), така че кодът за други архитектури не се отчита като покрит.

Така че излезте и изследвайте! Искам да кажа, проучете отчета, разберете кои части от нашия код не са обхванати и се опитайте да създадете тест, за да коригирате това. Очакваме вашата корекция в pgsql-hackers с интерес.

(Също така:има ли някакви тестове, които трябва да изпълним, освен make check-world ? Моля, оставете отзиви в коментарите).


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Транзакционни ли са функциите на PostgreSQL?

  2. КАСКАДНО ИЗТРИВАНЕ само веднъж

  3. Как да определите автоматично генерирания първичен ключ, използван като външен ключ за друга таблица

  4. Инсталирайте utf8 collation в PostgreSQL

  5. Има ли начин да се зададе време на изтичане, след което запис на данни се изтрива автоматично в PostgreSQL?