Re: Direction for test frameworks: Perl TAP vs. Python/pytest

On Wed, Jun 17, 2026 at 6:39 AM Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
> OK, so the consensus I'm sensing is that we should add a pytest
> framework, backpatch it into all the live branches, and initially port
> some relatively contained set of tests and backpatch that too.

As for "new tests that can't easily be written today": I've already
written several protocol-level tests for OAuth that implement broken
client and server behavior (they're in the pg-pytest-suite thread).
Those could be ported for review on top of the new framework. I could
look at some of the more recent ad-hoc Perl socket tests at the same
time.

> If I had
> to pick a candidate suite it would be the recovery tests (and my patch
> set conveniently contains a patch specifically for those).

No strong opinions here on the candidates for initial backport -- but
I will note that src/test/recovery doesn't look like a small slice, at
13k lines and more than half of the Test::Cluster API used.

> I guess
> that means the Test::Session work gets left on the cutting room floor -
> if we run into issues with perl tests the answer will be to convert them
> to pytest.

If you think Test::Session is good to go, I see no reason not to
improve the Perl tests (since there seems to be a growing consensus
that the conversion won't happen overnight).

--Jacob