Re: Contributing test cases to improve coverage

From: J F <jonathanfoo0523(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Contributing test cases to improve coverage
Date: 2024-06-12 19:51:48
Message-ID: CAEFLKGjncwibWsaoTwfaOKJt2AkgT5V4PHQVZ8=bWWUxNZFpgQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> I am quite confused about what is the point of this. You have not
> found any actual bug, nor have you demonstrated that this test case
> could discover a likely future bug that wouldn't be detected another
> way. Moreover, it seems like the process would lead to some very
> large number of equally marginal test cases. We aren't likely to
> accept such a patch, because we are concerned about keeping down the
> runtime of the test suite.
>
> regards, tom lane

The point of this project is to improve the coverage of PostgreSQL’s
preexisting test suite. Writing a test suite to achieve close to 100%
coverage is challenging, but I have proposed a workflow to automate this
process.

I assert that no test case in the regression test suite currently covers
the comparator in the expression rte->rtekind == RTE_SUBQUERY. I propose
adding a new test case that addresses exactly this. In the future, if
someone accidentally modifies the operator to become >=, it will trigger
incorrect behavior when certain queries are executed. This test case will
catch that issue.

I get that the test cases in /regress are likely reserved for actual bugs
found and are designed to run quickly. Would it be a good idea to have a
separate, more rigorous test suite that runs longer but provides better
code coverage?

Regards,
Jon

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michail Nikolaev 2024-06-12 20:02:00 Re: race condition in pg_class
Previous Message Noah Misch 2024-06-12 19:48:57 Re: race condition in pg_class