Hi Junio On 11 Feb 2022, at 15:07, Junio C Hamano wrote: > John Cai <johncai86@xxxxxxxxx> 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.
