Writing new unit tests with PostgresNode

From: Craig Ringer <craig(at)2ndquadrant(dot)com>
To: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Subject: Writing new unit tests with PostgresNode
Date: 2016-02-22 05:19:48
Message-ID: CAMsr+YEwd=j5xnbtN=BYbX49H=b7_F6y_9SU=kd_TDw8Quqp5A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi all

I've been taking a look at the Perl test infrastructure ( src/test/perl )
for writing multi-node tests, starting with PostgresNode.pm and I have a
few comments based on my first approach to the code "cold".

I think a README in src/test/perl/ would be very helpful. It's currently
not at all clear how to go about using the new test infrastructure when
first looking at it, particularly adding new test suites. Also a summary of
available test facilities and some short examples or pointers to where they
can be found ( src/bin/, src/test/ssl, etc).

The docs at http://www.postgresql.org/docs/devel/static/regress-tap.html
mention the use of tap for client programs but don't have anything on
writing/using the framework. It doesn't seem to be very close to /
compatible with http://pgtap.org/ unless I'm missing something obvious.

I want to add tests for failover slots but I'm not sure where to put them
or how to set up the test skeleton. So I went looking, and I could use
confirmation that the below is roughly right so I can write it up for some
quickstart docs.

It *looks* like one needs to create a Makefile with:

subdir = src/test/mytests
top_builddir = ../../..
include $(top_builddir)/src/Makefile.global

check:
$(prove_check)

clean:
rm -rf ./tmp_check

Then create a subdir src/test/mytests/t and in it put files named
001_sometest.pl etc. Each of which should import PostgresNode and generally
then create new instances indirectly via the PostgresNode::get_new_node
function rather than by using the constructor. Then init and start the
server and run tests. Like:

use strict;
use warnings;
use PostgresNode;
use TestLib;
use Test::More tests => 1;

diag 'Setting up node';
my $node = get_new_node('master');
$node->init;
$node->start;

my $ret = $node->psql('postgres', 'SELECT 1;');
is($ret, '1', 'simple SELECT');

$node->teardown_node;

Knowledge of perl's Test::More is required since most of the suite is built
on it.

The suite should be added to src/test/Makefile's ALWAYS_SUBDIRS entry.

Sound about right? I can tidy that up a bit and turn it into a README and
add a reference to that to the public tap docs to tell users where to go if
they want to write more tests.

I don't know how many suites we'll want - whether it'll be desirable to
have a few suites with lots of tests or to have lots of suites with just a
few tests. I'm planning on starting by adding a suite named 'replication'
and putting some tests for failover slots in there. Reasonable?

(BTW, the ssl tests don't seem to use a bunch of the facilities provided by
PostgresNode, instead rolling their own, so they don't serve as a good
example.)

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2016-02-22 05:32:44 Re: postgres_fdw vs. force_parallel_mode on ppc
Previous Message Pavel Stehule 2016-02-22 05:11:18 Re: Handling changes to default type transformations in PLs