Re: Explicitly skip TAP tests under Meson if disabled

From: Aleksander Alekseev <aleksander(at)timescale(dot)com>
To: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Cc: Peter Eisentraut <peter(at)eisentraut(dot)org>
Subject: Re: Explicitly skip TAP tests under Meson if disabled
Date: 2023-10-30 13:47:14
Message-ID: CAJ7c6TOS8rYm-MwTw8nGmMB3Hu7rmvS43JSLc4BLuONueTq2bw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

> Under Meson, it is not very easy to see if TAP tests have been enabled
> or disabled, if you rely on the default auto setting. You either need
> to carefully study the meson setup output, or you notice, what a minute,
> didn't there use to be like 250 tests, not only 80?
>
> I think it would be better if we still registered the TAP tests in Meson
> even if the tap_tests option is disabled, but with a dummy command that
> registers them as skipped. That way you get a more informative output like
>
> Ok: 78
> Expected Fail: 0
> Fail: 0
> Unexpected Pass: 0
> Skipped: 187
> Timeout: 0
>
> which is really a more accurate representation of what the test run
> actually accomplished than "everything Ok".
>
> See attached patch for a possible implementation. (This uses perl as a
> hard build requirement. We are planning to do that anyway, but
> obviously other implementations, such as using python, would also be
> possible.)

I tested the patch and it works as intended.

Personally I like the change. It makes the output more explicit. In my
use cases not running TAP tests typically is not something I want . So
I would appreciate being warned with a long list of bright yellow
"SKIP" messages. If I really want to skip TAP tests these messages are
just informative and don't bother me.

+1

--
Best regards,
Aleksander Alekseev

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bohdan Mart 2023-10-30 13:57:08 Including Doxyfile and Meson script for docs into main source tree
Previous Message Robert Haas 2023-10-30 13:43:02 Re: Is this a problem in GenericXLogFinish()?