Re: Another usability issue with our TAP tests - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Another usability issue with our TAP tests
Date
Msg-id 20180718003057.GE2998@paquier.xyz
Whole thread Raw
In response to Re: Another usability issue with our TAP tests  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: ENOSPC FailedAssertion("!(RefCountErrors == 0)"
Next
From: Robert Haas
Date:
Subject: Re: "Write amplification" is made worse by "getting tired" whileinserting into nbtree secondary indexes (Was: Why B-Tree suffix truncation matters)