Re: RFC: adding pytest as a supported test framework - Mailing list pgsql-hackers

From Jacob Champion
Subject Re: RFC: adding pytest as a supported test framework
Date
Msg-id CAOYmi+ng-7j6JTzD5pe3AutHZ=LAJqVN1ZGNQwKAOfA2MYiBfg@mail.gmail.com
Whole thread Raw
In response to Re: RFC: adding pytest as a supported test framework  ("Jelte Fennema-Nio" <postgres@jeltef.nl>)
Responses Re: RFC: adding pytest as a supported test framework
List pgsql-hackers
On Tue, Jan 6, 2026 at 11:07 AM Jelte Fennema-Nio <postgres@jeltef.nl> wrote:
> > That's fine by me, but I plan to focus on
> > things that need to get into PG19 before I focus on this, since
> > nothing is really blocked on it.
>
> Part of the reason why I've been trying to push this forward is that
> automated tests for the GoAway patch are definitely blocked on this. (The
> other reason is that I'd like to reduce the amount of perl I have to
> read/write.)

Ah, okay. To state publicly what I've already mentioned to you
off-list: I have absolutely no intention of going it alone on this. My
bar is enthusiastic buy-in from a number of maintainers (the price
paid for expanding the scope from "made-for-purpose protocol test
suite" to "eventual Test::Cluster replacement"), and no -1s. I expect
that to take a while.

It's perfectly okay if you'd like to tie the GoAway proposal to this,
but that seems like it's unlikely to result in short-term success. It
was in Drafts for a reason. The stated point of v2 was to "spark some
opinions and conversation", and I have no plans to fast-track this
patchset for 19.

> >> I think it'd be a seriously bad idea to start with no central infrastructure,
> >> we'd be force to duplicate that all over.
> >
> > Right, I just want central infra to be pulled out of the new tests
> > that need them rather than the other way around.
>
> I'm not sure how you expect that to work in practice.

Hopefully I'm just describing refactoring? Holding your nose,
open-coding it in a test even though you'd rather not, showcasing the
way you'd like to use it so we can discuss the style, and refactoring
it outwards and upwards in a later patch in the set, once you hit the
rule of three and there's a pattern of usage and an API that people
like. (This may have been what you're doing with v4 onwards, but again
I haven't been able to sit down with it.)

> I believe (and I
> think Andres too) that there's some infra that we already know we'll
> need for many tests, e.g. starting/stopping nodes, running queries,
> handling errors. [snip]

Sure -- I feel like I've already agreed with that upthread, ad
nauseam... along with my reasons why v2 hadn't tackled any of that
yet. I'd hoped to talk about the design questions I had in v2, but
it's OSS and no one is required to talk about things just because I
want them to. :D Your v3 rewrote it instead, and I haven't had time to
review v3 yet.

Writing code to start and stop a server and run SQL is a matter of
programming. Writing a test suite that newcomers can intuitively use,
and test interesting new things with, is a long-term collaboration. I
am much more interested in doing the latter, because we already have
the former, and personally I'm happy to build momentum slowly and wait
on a group of people who are in a good place to discuss it.

--Jacob



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: RFC: adding pytest as a supported test framework
Next
From: Jeff Davis
Date:
Subject: Re: small cleanup of ICU includes