Re: Testing with concurrent sessions

From: "David E(dot) Wheeler" <david(at)kineticode(dot)com>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Testing with concurrent sessions
Date: 2010-01-04 23:40:36
Message-ID: B030EA8B-E63B-40EC-A2B8-6B59A4463AE2@kineticode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Jan 4, 2010, at 3:29 PM, Peter Eisentraut wrote:

> If you're not deep into Perl, perhaps ignore the Test::More comment for
> the moment and just use DBI to connect to several database sessions,
> execute your queries and check if the results are what you want. Once
> you have gotten somewhere with that, wrapping a test harness around it
> is something others will be able to help with.

Last I heard, Andrew was willing to require Test::More for testing, so that a Perl script could handle multiple psql connections (perhaps forked) and output test results based on them. But he wasn't as interested in requiring DBI and DBD::Pg, neither of which are in the Perl core and are more of a PITA to install (not huge, but the barrier might as well stay low).

> pgTAP isn't really going to help you here, as it runs with *one*
> database session, and its main functionality is to format the result of
> SQL functions into TAP output, which is not very much like what you
> ought to be doing.

Right, exactly.

Best,

David

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2010-01-04 23:49:37 What's the current theory about derived files in VPATH builds?
Previous Message Andrew Dunstan 2010-01-04 23:38:03 Re: Initial refactoring of plperl.c - rebased [PATCH]