Re: debugging git tests, was: Re: [PATCH v4 2/8] t5520: test no merge candidates cases

Jeff King [off-list ref] writes:

On Mon, May 18, 2015 at 10:46:50AM -0700, Junio C Hamano wrote:

quoted

The test framework is aware of the fact that it needs to help the
people who are debugging the scripts.  The support is limited to the
case in which you run it under the -i option, i.e.

	$ cd t
        $ sh ./t5520-pull.sh -i -v

will refrain from running test_when_finished scripts when the test
piece fails.  Even though this is only limited to -i, I found it
often sufficient for debugging.

If you don't use "-i", you are pretty much screwed anyway, because the
subsequent tests will stomp all over the state of the test directory.

Yeah.

Many a head-scratching session has been caused by looking at the wrong
state, and these days my go-to options for debugging a test are "-v -i".
But since we are talking about it in a related thread, I will advertise
the new "-x" here, too.  :)

Yes, thanks for "-x".  That has been very helpful.

As a side note, I've also considered better support for running the
debugger on git commands inside a test (right now, I usually stick a
"gdb --args" in the pipeline, but you have to remember to run with "-v",
and to redirect stdin appropriately). Do other people have this
annoyance, too?

I usually tweak the script and have it stop before the offending
test, and then go through the steps in the test manually X-<.  If it
can be more automated, that would be great.

I haven't been ambitious enough to even attempt it so do not have
anything to add to the implementation ideas at this point.

I'm vaguely thinking of something like putting debug support into
bin-wrappers/git, but activating it only for certain tests (so you could
say "t5520-pull.sh --gdb=10", and git would start under the debugger
only for test 10). I think we'd also have to use gdbserver for I/O
sanity, and maybe provide short script to do:

   gdb -ex "target remote localhost:$some_port" "$TEST_DIRECTORY"/../git

That still doesn't cover all cases (when git spawns an external command,
you probably want to run the debugger on that; likewise, I have a
git-remote-debug hack for debugging remote-curl). I suspect with clever
use of gdb options that you could convince the original gdb invocation
to end up tracing the process you care about, though.

-Peff