Hi, Are there any updates to this problem?
Thank you, Alex On Wed, May 29, 2019 at 1:57 PM Johannes Schindelin <johannes.schinde...@gmx.de> wrote: > > 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
