Re: [PATCH v4 3/3] cat-file: add --batch-command mode

From: John Cai <johncai86@gmail.com>
Date: Feb 11, 2022, 21:30 UTC
Message-ID: <06C925DC-DAAC-4BA6-8CFA-E4ACF2039BB6@gmail.com>
In-Reply-To: <xmqqpmnt9ngx.fsf@gitster.g>

Hi Junio

On 11 Feb 2022, at 15:07, Junio C Hamano wrote:

Show 16 quoted lines

> John Cai <johncai86@gmail.com> writes:
>
>> Let me see if I understand you. What I'm hearing is that it's hard to test a git
>> processes (A) that read/write from/to pipes without knowing exactly how (A) will
>> behave. By necessity, the test logic will have embedded some logic in it that
>> assumes certain behavior from (A), which might or might not be the case.
>>
>> This can lead to a hanging test if, say, it is waiting around for (A) to output
>> data when due to a bug in the code, it never does. Did I get that right?
>
> Exactly.  And we've seen such tests that are designed to hang, when
> they detect bugs, which made us very unhappy and we fixed them not
> to hang but reliably fail.  Otherwise, such tests weren't very
> useful in unattended CI environment, which we do not want to wait
> for 3 hours to timeout and leave later steps in the same script
> untested.

That makes sense. Do you have an example of one of these tests? I'd like to see how it was converted from a test that hung to a test that failed reliably. As I'm thinking about converting run_buffer_test_flush() and run_buffer_test_no_flush() into tests that fail rather than hang, I'm having a hard time avoiding the pattern of A writes to B and waits for B to respond.

>
> Thanks.