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: