Fabien COELHO <coe...@cri.ensmp.fr> writes:
>> If we're sufficiently dead set on it, we could go back to the TAP-based
>> approach,
> Hmmm. You rejected it. I agree that TAP tests are not well suited for some
> simple tests because of their initdb overhead.
>> but I still doubt that this test is worth the amount of overhead that
>> would add.
> I think that there is an underlying issue with keeping on rejecting tests
> which aim at having a reasonable code coverage of features by exercising
> different paths.
There's certainly a fair amount of psql behavior that's not adequately
testable within the standard regression test infrastructure. Parsing of
command line arguments and exit codes for unusual cases both fall into
that area, and then there's things like prompts and tab completion.
If someone were to put together a TAP test suite that covered all that
and made for a meaningful improvement in psql's altogether-miserable
code coverage report[1], I would think that that would be a useful
expenditure of buildfarm time. What I'm objecting to is paying the
overhead for such a suite in order to test just this one thing. I don't
think that that passes the bang-for-buck test; or in other words, this
isn't the place I would start if I were creating a TAP suite for psql.
regards, tom lane
[1] https://coverage.postgresql.org/src/bin/psql/index.html
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
