Re: Improving test coverage of extensions with pg_dump - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Improving test coverage of extensions with pg_dump
Date
Msg-id CAB7nPqSRiPgXQtm0vQ5Fx_webPaje-YAESOD8Y9bfC2xDZHrNQ@mail.gmail.com
Whole thread Raw
In response to Re: Improving test coverage of extensions with pg_dump  (Andreas Karlsson <andreas@proxel.se>)
Responses Re: Improving test coverage of extensions with pg_dump  (Michael Paquier <michael.paquier@gmail.com>)
List pgsql-hackers
On Fri, Jul 31, 2015 at 6:41 AM, Andreas Karlsson <andreas@proxel.se> wrote:
> The comment is good, but what I personally do not like is that the path to
> the test suite is non-obvious and not self explanatory I would not expect
> src/test/tables_fk/t/ to test pg_dump and extensions. I find it to confusing
> to regard the test suite as testing an extension called "tables_fk" since in
> my mind that is just a necessary tool built to test something else.
>
> This is obviously a subjective thing, and I see that for example Heikki
> likes it the way it is. I am fine with setting this as ready for committer
> and and let a committer weigh in on the naming.

Well, honestly, I would just have it in src/test/modules and call it a
deal. Because it is now the only extension that has such interactions
with perl tests. And because if modules/ gets bloated later on, we
could extend prove_check to install modules from extra paths, just
that it does not seem worth it to do it now for one module, and there
is no guarantee that we'll have that many around. Of course there is
no guarantee either that modules/ is not going to get bloated.

Note as well that I will be fine with any decision taken by the
committer who picks up this, this test case is useful by itself in any
case.
-- 
Michael



pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: TAP tests are badly named
Next
From: Michael Paquier
Date:
Subject: Re: creating extension including dependencies