Phillip Wood <phillip.wood123@xxxxxxxxx> writes: >> + type=$1 >> + sha1=$2 >> + size=$3 >> + >> + mkfifo input && >> + test_when_finished 'rm input' && >> + mkfifo output && >> + exec 9<>output && >> + test_when_finished 'rm output; exec 9<&-' >> + ( >> + # TODO - Ideally we'd pipe the output of cat-file >> + # through "sed s'/$/\\/'" to make sure that that read >> + # would consume all the available >> + # output. Unfortunately we cannot do this as we cannot >> + # control when sed flushes its output. We could write >> + # a test helper in C that appended a '\' to the end of >> + # each line and flushes its output after every line. >> + git cat-file --buffer --batch-command <input 2>err & >> + echo $! && >> + wait $! >> + ) >&9 & >> + sh_pid=$! && >> + read cat_file_pid <&9 && >> + test_when_finished "kill $cat_file_pid >> + kill $sh_pid; wait $sh_pid; :" && >> + echo "$sha1 $type $size" >expect && >> + test_write_lines "info $sha1" flush "info $sha1" >input > > This closes input and so cat-file exits and flushes its output - > therefore you are not testing whether flush actually flushes. When I > wrote this test in[1] this line was inside a subshell that was > redirected to the input fifo so that the read happened before cat-file > exited. Yeah, very good point. > This test is also not testing the exit code of cat-file or > that the output is flushed on exit. Is there a reason you can't just > use the test as I wrote it? I'm happy to explain anything that isn't > clear. I admit I do not offhand recall what your tests did but help with this (and more) level of detail with an offer to collaborate is something I am very happy to see. Thanks for working well together. One thing that I wasn't quite sure was how well failure cases are tested. If we ask, in a batch mode, "info" for two objects and then "flush", does the asker get enough clue when to read and when to stop reading with all four combinations of states, i.e. asking for two missing objects, one good object and one bad object, one bad object and one good object, two good objects, for example? Testing such combinations reliably is tricky---if the asker needs to react to different response differently, a test that expects good and then bad may not just fail but can get into deadlock, for example if the reaction to good response has to read a lot but the reaction to bad response is to just consume the "bad object" notice, when a bug in the program being tested makes it issue the response for a bad case when the asker is expecting a response for a good object, because the asker will keep waiting for more response to read which may not come.
