Re: Adding "large" to PG_TEST_EXTRA - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Adding "large" to PG_TEST_EXTRA
Date
Msg-id 20230213234423.vt5fdivbksf3gtal@awork3.anarazel.de
Whole thread Raw
In response to Re: Adding "large" to PG_TEST_EXTRA  (Peter Smith <smithpb2250@gmail.com>)
Responses Re: Adding "large" to PG_TEST_EXTRA
List pgsql-hackers
Hi,

On 2023-02-14 09:26:47 +1100, Peter Smith wrote:
> I've observed suggested test cases get rejected as being overkill, or
> because they would add precious seconds to the test execution. OTOH, I
> felt such tests would still help gain some additional percentages from
> the "code coverage" stats. The kind of tests I am thinking of don't
> necessarily need a huge disk/CPU - but they just take longer to run
> than anyone has wanted to burden the build-farm with.

I'd say it depend on the test whether it's worth adding. Code coverage for its
own sake isn't that useful, they have to actually test something useful. And
tests have costs beyond runtime, e.g. new tests tend to fail in some edge
cases.

E.g. just having tests hit more lines, without verifying that the behaviour is
actually correct, only provides limited additional assurance.  It's also not
very useful to add a very expensive test that provides only a very small
additional amount of coverage.

IOW, even if we add more test categories, it'll still be a tradeoff.


> Sorry for the thread interruption -- but I thought this might be the
> right place to ask: What is the recommended way to deal with such
> tests intended primarily for better code coverage?

I don't think that exists today.

Do you have an example of the kind of test you're thinking of?


Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: recovery modules
Next
From: Jeff Davis
Date:
Subject: Re: Rework of collation code, extensibility