Re: [HACKERS] Inadequate traces in TAP tests

Поиск
Список
Период
Сортировка
От Craig Ringer
Тема Re: [HACKERS] Inadequate traces in TAP tests
Дата
Msg-id CAMsr+YEKim8vN+VTO3KsUeEStudPgTGJq-WqjcSEoR1T3k0ygQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Inadequate traces in TAP tests  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [HACKERS] Inadequate traces in TAP tests  (Andrew Dunstan <andrew.dunstan@2ndquadrant.com>)
Список pgsql-hackers


On 20 Mar. 2017 22:10, "Tom Lane" <tgl@sss.pgh.pa.us> wrote:

FWIW, the problem I've got with the TAP tests is that when one fails
in the buildfarm, you've got to dig through megabytes of all-alike-looking
output just to try to determine which one failed; and once you do, you
still know nothing because the script output never really says why it
thinks there was a problem.

Yeah, it's not super helpful.

I'd like to enable Carp's features to use confess for traces, and switch all use of die to that. We could learn a lot about unplanned-for test failures where a test script dies rather than failing a test if we used carp effectively.



  If you're lucky, you can identify the
postmaster log file(s) corresponding to the failed test script

What's the problem with doing that?

Maybe we need to structure the build farm output better. Send an archive of tmp_check/logs/ or mime-multipart it or something, so it's all cleanly split up.


I am *absolutely* not in favor of adding anything to the scripts' routine
output, because it will just make this problem worse by bloating the
buildfarm logs even more.  What I'd like to see is for the scripts to
always report something along the lines of "this is what I got, this is
what I expected to get" --- but only when there is a failure.

That's what they -should- do already, with 'ok', 'is', etc tests. Though sometimes diagnostic output is useful we should be using 'note' to dump it in the script's log, not in its main output. Whenever possible we should be using TAP facilities to only emit it when there is a failure - most usefully just by testing the test return code e.g. 

if (!is(some_test, 1, 'test description')) {
  diag "useful info: $relevant_variable";
}

TAP has a diag like function that dumps data structures too, Data::Dumper style.

Hm. Maybe the tap test readme needs a mini test writing style guide. Very mini.

BTW I've used diag in a few and those should be either changed to note or moved to post-fail. Will post a patch.



The less
output there is from a successful test, the better, IMO.

The trouble there is that we don't always know we're going to fail. Nor will we always fail in a clean, anticipated way. A test script might die because some setup it does fails with an unexpected ERROR for example.

That's why I think some diagnostic output is good. But it should definitely be in the script logs not the main TAP output. And it should be moderate.

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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] [COMMITTERS] pgsql: Improve pg_dump regression tests and code coverage
Следующее
От: Stephen Frost
Дата:
Сообщение: Re: [HACKERS] Inadequate traces in TAP tests