Re: RFC: adding pytest as a supported test framework

On Mon Jan 5, 2026 at 9:19 PM CET, Jacob Champion wrote:
> On Wed, Dec 17, 2025 at 8:10 AM Andres Freund <andres(at)anarazel(dot)de> wrote:
> Before it gets too far away from me: note that I have not yet been
> able to get up to speed with the combined refactoring+feature patch
> that Jelte added in v3, and it's now up to v7,

Attached is v8. It simplifies the Cirrus CI yaml, because the
dependencies are now baked into the images. I also removed the optional
dependency on uv. Meson/autoconf now simply search for pytest binary in
the .venv directory too. Devs can then choose if they want to populate
.venv with pip or uv. Finally, if the pytest binary cannot be found,
there's a fallback attempt to use `python -m pytest`.

> 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.)

>> > -SUBDIRS = perl postmaster regress isolation modules authentication recovery subscription
>> > +SUBDIRS = \
>> > + authentication \
>> > + isolation \
>> > + modules \
>> > + perl \
>> > + postmaster \
>> > + pytest \
>> > + recovery \
>> > + regress \
>> > + subscription
>>
>> I'm onboard with that, but we should do it separately and probably check for
>> other cases where we should do it at the same time.
>
> I'm not sure what context this is referring to? What are you on board with?

If I understood Andres correctly this was about splitting the items
across multiple lines. I moved this to a separate thread, and it was
cammitted by Michael in 9adf32da6b. So this has been resolved afaik.

>> 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. 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. I don't think it makes sense to have those be pulled
out of new tests. You need some basics, otherwise no-one will want to
write tests. And even if they do, everyone ends up with different styles
of doing basic things. I'd rather coordinate on a bit of style upront so
that tests behave similarly for common usages.