Re: Mop-up from Test::More version change patch

From: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, Noah Misch <noah(at)leadboat(dot)com>
Subject: Re: Mop-up from Test::More version change patch
Date: 2021-11-24 07:40:56
Message-ID: 3cbf0b23-4cc0-f6c8-62f2-3a1bff23cb44@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 23.11.21 18:03, Tom Lane wrote:
> 0002 is written to apply to v14 and earlier, and what it wants
> to do is back-patch the effects of 405f32fc4, so that the
> minimum Test::More version is 0.98 in all branches. The thought
> here is that (1) somebody is likely to want to back-patch a
> test involving Test::More::subtest before too long; (2) we have
> zero coverage for older Test::More versions anyway, now that
> all buildfarm members have been updated to work with HEAD.

The backpatching argument is a little off-target, I think. The purpose
of subtests is so that wrappers like command_fails_like() count only as
one test on the outside, instead of however many checks it runs
internally. There is no use in using the subtest feature in a top-level
test one might add, say in response to a bugfix. So the only reason
this might become relevant is if someone were to backpatch new test
infrastructure, which seems rare and in most cases would probably
require additional portability and backpatching care. And even then,
you still need to adjust the test count at the top of the file
individually in each branch, because the total number of tests will
probably be different.

In my mind, the subtests feature is useful during new development, where
you write a bunch of new tests and want to set the total test count by
eyeballing what you just wrote instead of having to run test cycles and
react to the complaints. But it won't be useful for patching tests into
existing files.

In summary, I would leave it alone.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2021-11-24 07:48:27 Re: Post-CVE Wishlist
Previous Message Peter Eisentraut 2021-11-24 07:24:52 Re: Python 3.11 vs. Postgres