Re: Another usability issue with our TAP tests

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Another usability issue with our TAP tests
Date: 2018-07-18 00:30:57
Message-ID: 20180718003057.GE2998@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jul 17, 2018 at 03:02:32PM -0400, Tom Lane wrote:
> Cute idea, but it seems not to work with older versions of prove:
>
> $ which prove
> /usr/local/perl5.8.3/bin/prove
> $ prove --state=save
> Unknown option: s

I didn't know this one, and that's actually nice, but I cannot get
easily a way to track down which tests failed during a parallel run...
And I am used as well to hunt those with "git status".

> We could just do a "touch .prove_running" beforehand and an "rm" after,
> perhaps (I think Michael suggested something like that already).

Yes, except that in the idea of upthread TestLib.pm would be in control
of it, so as there is less code churn in prove_check and
prove_installcheck. But I am having second-thoughts about putting the
test state directly in the module as that's a four-liner in
Makefile.global.in, and that seems to work even if you put a die() to
fail hard or even if only a subset of tests is failing.

Thoughts?
--
Michael

Attachment Content-Type Size
tap-running-marker.patch text/x-diff 1.0 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2018-07-18 00:45:42 Re: "Write amplification" is made worse by "getting tired" while inserting into nbtree secondary indexes (Was: Why B-Tree suffix truncation matters)
Previous Message Tom Lane 2018-07-18 00:01:05 Re: ENOSPC FailedAssertion("!(RefCountErrors == 0)"