Hello Tom,
>> The point is that there would be at least *one* TAP tests so that many
>> other features of psql, although not all, can be tested. [...]
>
> Yeah, but the point I was trying to make is that that's mostly down to
> laziness.
Not always.
I agree that using TAP test if another simpler option is available is not
a good move.
However, in the current state, as soon as there is some variation a test
is removed and coverage is lost, but they could be kept if the check could
be against a regexp.
> I see no reason that we couldn't be covering a lot of these features in
> src/test/regress/sql/psql.sql, with far less overhead. The interactive
> aspects of psql can't be tested that way ... but since this patch
> doesn't actually provide any way to test those, it's not much of a
> proof-of-concept.
The PoC is checking against a set of regexp instead of expecting an exact
output. Ok, it does not solve all possible test scenarii, that is life.
> IOW, the blocking factor here is not "does src/bin/psql/t/ exist",
> it's "has somebody written a test that moves the coverage needle
> meaningfully". I'm not big on adding a bunch of overhead first and
> just hoping somebody will do something to make it worthwhile later.
I do intend to add coverage once a psql TAP test is available, as I have
done with pgbench. Ok, some of the changes are still in the long CF queue,
but at least pgbench coverage is around 90%.
I also intend to direct submitted patches to use the TAP infra when
appropriate, instead of "no tests, too bad".
--
Fabien.
