git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH v2 1/2] test-lib: add a function to compare an expection with stdout from a command

From
Eric Sunshine <sunshine@sunshineco.com>
Date
Apr 17, 2016, 06:36 UTC
Message-ID
<CAPig+cTOa2yaMikOJHQXpSjY_EtyUXaqVz4KobQwO2xn=Q6h_w@mail.gmail.com>
In-Reply-To
<20160417035414.GA30002@sigill.intra.peff.net>
On Sat, Apr 16, 2016 at 11:54 PM, Jeff King <peff@peff.net> wrote:
Show 37 quoted lines
> On Sat, Apr 16, 2016 at 11:07:02PM -0400, Eric Sunshine wrote:
>> > test_stdout accepts an expection and a command to execute.  It will execute
>> > the command and then compare the stdout from that command to an expectation.
>> > If the expectation is not met, a mock diff output is written to stderr.
>>
>> I wonder if this deserves more flexibility by accepting a comparison
>> operator, such as = and !=, similar to test_line_count()? Although, I
>> suppose such functionality could be added later if deemed useful.
>
> [...] Though I do actually find that:
>
>   test_stdout false git rev-parse --whatever
>
> isn't great, because there's no syntactic separator between the expected
> output and the actual command to run. So I dunno, maybe it would be
> better as:
>
>   test_stdout false = git rev-parse --whatever
>
> [...] We could also do:
>
>   test_stdout git rev-parse --whatever <<-\EOF
>   false
>   EOF
>
> which is more robust for multi-line output, but I think part of the
> point is to keep these as simple one-liners. You're not buying all that
> much over:
>
>   cat >expect <<-\EOF &&
>   false
>   EOF
>   git rev-parse --whatever >actual &&
>   test_cmp expect actual
>
> Though I do admit I've considered such a helper for some tests where
> that pattern is repeated ad nauseam.

Agreed. I wouldn't mind the version where test_stdout grabs "expected" from <<EOF, but, as you say, it doesn't buy much over the manually prepared test_cmp version.

I suppose that the one-liner form of test_stdout could have its uses, however, it bothers me for a couple reasons: (1) it's not generally useful like the version which grabs "expected" from <<EOF, (2) it squats on a nice concise name which would better suit the <<EOF version.

Anyhow, this may all be moot (for now) since I think this patch series is going in the wrong direction entirely by abandoning the systematic approach taken by the original t1500 code, as explained in my review[1]. If modernization of t1500 retains a systematic approach, then the repetitive code which prompted the suggestion of test_stdout won't exist in the first place.

[1]: http://article.gmane.org/gmane.comp.version-control.git/291745
Previous: Jeff KingNext: Jeff King
Message 5 of 13 in “t1500-rev-parse: re-write t1500”
  1. 0/2 t1500-rev-parse: re-write t1500Michael Rappazzo, Apr 16, 2016
  2. 1/2 test-lib: add a function to compare an expection with stdout from a commandMichael Rappazzo, Apr 16, 2016
  3. Eric SunshineApr 17, 2016
  4. Jeff KingApr 17, 2016
  5. Eric SunshineApr 17, 2016
  6. Jeff KingApr 17, 2016
  7. Johannes SixtApr 17, 2016
  8. Eric SunshineApr 17, 2016
  9. 2/2 t1500-rev-parse: rewrite each test to run in isolationMichael Rappazzo, Apr 16, 2016
  10. Eric SunshineApr 17, 2016
  11. Johannes SixtApr 17, 2016
  12. SZEDER GáborApr 17, 2016
  13. Eric SunshineApr 17, 2016

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.