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

From Victor Wagner
Subject Re: [REVIEW] In-core regression tests for replication, cascading, archiving, PITR, etc.
Date
Msg-id 20160204211841.57076a47@wagner.wagner.home
Whole thread Raw
In response to Re: Re: In-core regression tests for replication, cascading, archiving, PITR, etc.  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: [REVIEW] In-core regression tests for replication, cascading, archiving, PITR, etc.
Re: [REVIEW] In-core regression tests for replication, cascading, archiving, PITR, etc.
List 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 by date:

Previous
From: Victor Wagner
Date:
Subject: Re: In-core regression tests for replication, cascading, archiving, PITR, etc.
Next
From: David Steele
Date:
Subject: Re: UNIQUE capability to hash indexes