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.
