Re: [REVIEW] In-core regression tests for replication, cascading, archiving, PITR, etc.

Поиск
Список
Период
Сортировка
От Victor Wagner
Тема Re: [REVIEW] In-core regression tests for replication, cascading, archiving, PITR, etc.
Дата
Msg-id 20160204211841.57076a47@wagner.wagner.home
обсуждение исходный текст
Ответ на Re: Re: In-core regression tests for replication, cascading, archiving, PITR, etc.  (Michael Paquier <michael.paquier@gmail.com>)
Ответы Re: [REVIEW] In-core regression tests for replication, cascading, archiving, PITR, etc.  (Michael Paquier <michael.paquier@gmail.com>)
Re: [REVIEW] In-core regression tests for replication, cascading, archiving, PITR, etc.  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Список pgsql-hackers
This patch adds a long-awaited functionality to the PostgreSQL test
suite - testing of cluster configuration.

It contains bare minimum of replication and recovery test, but it should
be a good starting point for other people. 

Really, adding a much more tests for replication and recovery
is problematic, because these tests are resource-hungry, and take big
enough time even on relatively powerful machines, but  it seems to be
necessary, because they need to create several temporary installation.

So, set of tests, included into this patch is reasonably good choice. 

I think that readability of tests can be improved a bit, because these
tests would serve as an example for all tap test writers.

It's quite good that patch sets standard of using 'use strict; use
warnings;' in the test script.

It is bad, that Postgres-specific perl modules do not have embedded
documentation. It would be nice to see POD documentation in the
TestLib.pm and PostgresNode.pm instead of just comments. It would be
much easier to test writers to read documentation using perldoc utility,
rather than browse through the code.

I'll second Stas' suggestion about psql_ok/psql_fail functions.

1. psql_ok instead of just psql would provide visual feedback for the
reader of code. One would see 'here condition is tested, here is
something ended with _ok/_fail'.

It would be nice that seeing say "use Test::More tests => 4"
one can immediately see "Yes, there is three _ok's and one _fail in the
script'

2. I have use case for psql_fail code. In my libpq failover patch there
is number of cases, where it should be tested that connection is not
established,

But this is rather about further evolution of the tap test library, not
about this set of tests.

I think that this patch should be commited as soon as possible in its
current form (short of already reported reject in the PostgresNode.pm
init function).


--                                   Victor Wagner <vitus@wagner.pp.ru>



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Victor Wagner
Дата:
Сообщение: Re: In-core regression tests for replication, cascading, archiving, PITR, etc.
Следующее
От: David Steele
Дата:
Сообщение: Re: UNIQUE capability to hash indexes