Re: Another usability issue with our TAP tests

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: Another usability issue with our TAP tests
Дата
Msg-id 20180718003057.GE2998@paquier.xyz
обсуждение исходный текст
Ответ на Re: Another usability issue with our TAP tests  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: ENOSPC FailedAssertion("!(RefCountErrors == 0)"
Следующее
От: Robert Haas
Дата:
Сообщение: Re: "Write amplification" is made worse by "getting tired" whileinserting into nbtree secondary indexes (Was: Why B-Tree suffix truncation matters)