Jeff King <peff@xxxxxxxx> writes: > On Sat, Jun 29, 2024 at 05:35:31PM +0200, René Scharfe wrote: > >> Provide the expected output of "test-tool example-tap" verbatim instead >> of as a here-doc, to avoid distractions due to quoting, variables >> containing quotes and indentation. > > I'm not really opposed to this patch, but I wondered... > >> test_expect_success 'TAP output from unit tests' ' >> - cat >expect <<-EOF && >> - ok 1 - passing test >> - ok 2 - passing test and assertion return 1 > > If you could take the test input on stdin, like so: > > test_expect_success 'TAP output from unit tests' - <<-\EOT > cat >expect <<-\EOF > ok 1 - passing test > ok 2 - passing test and assertion return 1 > [...] > # check "'a' == '\n'" failed at t/helper/test-example-tap.c:64 > # left: 'a' > # right: '\012' > [...] > EOF > EOT > > would that be preferable to moving it to its own file? I kind of like > keeping everything in the test scripts themselves so related changes can > happen side-by-side, though I admit in this case it is intimately tied > to the separate test-example-tap.c source anyway. Yeah, it does feel a bit of cop-out to separate the expectation out to an external file. I guess I was to blame for things like t4013 but there is a valid excuse there (it would be expected that similar tests would need to be added and one test per one expected result was a natural way to manage hundreds of tests). In this case, I think the fact that validating the test framework is an oddball use case is a sufficient excuse ;-). > But I do have such an "EOT" patch which I've been meaning to send out, > since it makes many of these quoting annoyances go away (though of > course it leaves the indentation). I am not sure about your "test body comes from the standard input" (not saying "I am not convinced it is a good idea" or even "I am convinced it is a bad idea"---I do not know what to think about it, not just yet). THe above illustration does make it easier to grok by keeping everything in one place. Thanks.
