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

From: Victor Wagner <vitus(at)wagner(dot)pp(dot)ru>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: [REVIEW] In-core regression tests for replication, cascading, archiving, PITR, etc.
Date: 2016-02-04 18:18:41
Message-ID: 20160204211841.57076a47@wagner.wagner.home
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)wagner(dot)pp(dot)ru>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Steele 2016-02-04 18:19:52 Re: UNIQUE capability to hash indexes
Previous Message Victor Wagner 2016-02-04 18:13:46 Re: In-core regression tests for replication, cascading, archiving, PITR, etc.