Hi Peff, On Tue, 28 May 2019, Jeff King wrote: > On Tue, May 28, 2019 at 01:06:21PM +0200, Johannes Schindelin wrote: > > > > Or do you prefer having a one-liner? I'd rather come up with a more > > > generic helper to cover this case, that can run any command and compare > > > it to a single argument (or stdin). E.g.,: > > > > > > test_cmp_cmd no-conflict git log -1 --format=%s > > > > > > or > > > > > > test_cmp_cmd - git foo <<-\EOF > > > multi-line > > > expectation > > > EOF > > > > I guess that you and me go into completely opposite directions here. I > > want something *less* general. Because I want to optimize for the > > unfortunate times when a test fails and most likely somebody else than the > > original author of the test case is tasked with figuring out what the heck > > goes wrong. > > > > You seem to want to optimize for writing test cases. Which I find -- with > > all due respect -- the wrong thing to optimize for. It is already dirt > > easy to write new test cases. But *good* test cases (i.e. easy to debug > > ones)? Not so much. > > Hmm. I too want the test output to be useful to people other than the > test author. But I find the output from test_cmp perfectly fine there. > My first step in digging into a failure is usually to look at what > commands the test is running, which generally makes it obvious why we > are expecting one thing and seeing another (or at least, just as obvious > as a hand-written message). > > So to me the two are equal on that front, which makes me want to go with > the thing that is shorter to write, as it makes it more likely the test > writer will write it. The _worst_ option IMHO is a straight-up use of > "test" which provides no output at all in the test log of what value we > _did_ see. That requires the person looking into the failure to re-run > the test, which is hard if it's a remote CI, or if the failure does not > always reproduce. If you think your version is easier to debug, then I won't object. Thanks, Dscho
