Re: Improving test coverage of extensions with pg_dump

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: Improving test coverage of extensions with pg_dump
Дата
Msg-id CAB7nPqSRiPgXQtm0vQ5Fx_webPaje-YAESOD8Y9bfC2xDZHrNQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Improving test coverage of extensions with pg_dump  (Andreas Karlsson <andreas@proxel.se>)
Ответы Re: Improving test coverage of extensions with pg_dump  (Michael Paquier <michael.paquier@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: TAP tests are badly named
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: creating extension including dependencies