From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Peter Smith <smithpb2250(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Adding "large" to PG_TEST_EXTRA |
Date: | 2023-02-13 23:44:23 |
Message-ID: | 20230213234423.vt5fdivbksf3gtal@awork3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Davis | 2023-02-13 23:45:41 | Re: Rework of collation code, extensibility |
Previous Message | Andres Freund | 2023-02-13 23:37:33 | Re: recovery modules |