On Mon, Jul 01, 2024 at 09:51:31PM +0200, René Scharfe wrote: > > 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. > > I can't think of an example where we keep test definitions in the same > file as the code to be tested. It would be somewhat cool to empower the > unit test framework to test itself, but I suspect that this nesting > ability would be hard to achieve and not very useful otherwise. And > would we be able to trust such a self-test? Yeah, I think this is really a special case, just because we're not testing specific items, but rather sanity-checking the TAP output itself. I think even in the unit tests, we're mostly carrying expected output next to the code (and the unit test harness is checking those and producing appropriate messages). It's only this "run a bunch of tests that might themselves fail and see if the output was sensible" that it's hard to do this for. I.e., t0080 is special and weird. > The only downside of keeping the expected output of t0080 separate that > I can think of is that it might get confusing if we'd ever add more > test_expect_success calls to it, but I can't imagine why we'd want to > do that. Yeah, I think it is mostly a lost cause here. We are far away from the source code whether it is a here-doc or a separate file. I guess I was responding more to the principle that external files are usually just distracting and annoying (another annoyance: they inhibit tab completion ;) ). But it is not that big a deal either way in this case. > Being able to pass the test code to test_expect_success as a here-doc or > file to avoid nested shell quoting sounds useful in general. For t0080 > we could achieve the same effect already by creating the expect file > before calling test_expect_success. That has the downside of passing > even when the disk is full and the files are created empty, but we can > throw in a "test -s" to rule it out. Yup, agreed with everything there. -Peff
