Re: convert libpq uri-regress tests to tap test
Peter Eisentraut <peter.eisentraut@enterprisedb.com>
From: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andres Freund <andres@anarazel.de>, pgsql-hackers@postgresql.org
Date: 2022-02-24T12:31:40Z
Lists: pgsql-hackers
On 24.02.22 02:52, Tom Lane wrote: > Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes: >> On 23.02.22 23:58, Tom Lane wrote: >>> Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes: >>>> libpq TAP tests should be in src/interfaces/libpq/t/. > >>> That's failing to account for the fact that a libpq test can't >>> really be a pure-perl TAP test; you need some C code to drive the >>> library. > >> Such things could be put under src/interfaces/libpq/test, or some other >> subdirectory. We already have src/interfaces/ecpg/test. > > OK, but then the TAP scripts are under src/interfaces/libpq/test/t, > which isn't what you said. I have no great objection to moving > src/test/modules/libpq_pipeline/ to src/interfaces/libpq/test/, > though, as long as the buildfarm will cope. I think the TAP scripts should be in src/interfaces/libpq/t/, as usual. The supporting code snippets could live in some other directory under src/interfaces/libpq/, which might be called "test" or something else, not that important. I think we should pick a layout that is proper and future-proof and then adjust the buildfarm client as necessary. The issue of writing libpq-specific tests has come up a few times recently; I think it would be worth finding a proper solution to this that would facilitate that work in the future.
Commits
-
Run tests of libpq on installcheck-world, checkprep and check-world
- 2cc96f233914 15.0 landed
-
Convert src/interfaces/libpq/test to a tap test.
- ac25173cdbc4 15.0 landed
-
Run tap tests in src/interfaces/libpq.
- 6b04abdfc5e0 15.0 landed