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
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()? |