Subject: Re: [PATCH 0/4] meson: parse TAP output generated by our tests

From: Todd Zullinger <[email-masked]>
Date: Mon, 26 May 2025 10:23:04 -0400

Phillip Wood wrote:
> On 26/05/2025 13:44, Patrick Steinhardt wrote:
>> 
>> I don't think it's inherently a bad thing to fail on unexpected passes.
>> After all, it shows that our assumption that the test fails is broken,
>> and that we should have a look why that is. But I can see arguments both
>> ways.
> 
> Personally I'd be very happy if our test suite failed on an unexpected pass.
> Currently it is easy to miss, especially if the unexpected pass occurs in a
> CI run. Missing an unexpected pass means we don't change
> 'test_expect_failure' to 'test_expect_pass' and a future regression that
> causes the test to fail again will go unnoticed.

Indeed.  Perhaps related (apologies if it's a wild tangent),
having a way to expose an unexpectedly failed prereq would
be nice.

For example, we currently (well, last time I checked, which
was a month or so ago) fail the GPG2 prereq.  I submitted
small patch series to fix that nearly a year ago¹, but when
I ran the tests in our CI, they turned up some preexisting
failures.

I spent a little time trying to reproduce and resolve the
failures, but was never able to make it work.  These tests
pass when run locally which makes it painful to track down.

It would have been ideal if they failed when added, so that
it could have been worked out during the review period,
while it was fresh in the minds of the folks working in that
area.

We are simply not noticing these failures in our CI, which
feels worse than simply not having test coverage.  It gives
a false of security that t/t1016-compatObjectFormat.sh is
passing.  In reality, the tests might be reporting a real
issue that we've been missing for ages.

¹ <[email-masked]>

-- 
Todd