Fabien COELHO <coelho@cri.ensmp.fr> writes:
>> No, I disagree with that. If configure thinks it built with readline,
>> and then the actual binary acts like it doesn't have readline, that's
>> a bug that we'd like the tests to detect.
> Hmmm. Sure, that's a point.
> What about running some tests on an installed version?
I think "make installcheck" has plenty of dependencies already on the
build tree matching the installed version. For instance, src/pl
will/won't run regression tests on languages it thinks was/weren't built.
If you want to run such tests retroactively, you'd better make sure you
configure your build tree to match the existing installation.
>> I mainly just duplicated the environment set up by PostgresNode::psql
>> as much as it seemed reasonable to. The -At options are kind of
>> irrelevant for what we're going to test here, probably, but why not
>> keep the default behavior the same? I did drop -q since that
>> suppresses prompting, and we probably want to test prompt.c using
>> this infrastructure.
> That is what my patch does: it tests prompts, tab completion, help,
> command options… and I added tests till I covered most psql source.
Well, I think that where possible we ought to test using the existing test
infrastructure -- help, for example, seems like it could perfectly well be
tested in src/test/regress/sql/psql.sql, or we could move stuff out to a
new set of SQL test scripts under src/bin/psql/sql/, if it seems like we
don't need it to be part of the core tests. But any tests using this new
infrastructure are going to be skipped by some percentage of test
machines, so we shouldn't skip what needn't be skipped.
regards, tom lane