On 22/12/12 01:35PM, Eric Sunshine wrote: > On Mon, Dec 12, 2022 at 1:19 PM Ævar Arnfjörð Bjarmason > <avarab@xxxxxxxxx> wrote: > > On Mon, Dec 12 2022, Jacob Abel wrote: > > > Also, Is there an easier way to debug the `test_expect_success` statements? I > > > tried enabling tracing mode but it doesn't seem to trace into those statements. > > > > Not really, other than just enabling "-x" for the test-lib.sh itself, i.e.: > > > > sh -x ./t0001-init.sh > > > > I *think* that should work, but I didn't test it... > > Isn't the question here how to debug the body of a > test_expect_success? If that's the case, then running the test with -x > and -i should help: > > ./t001-init.sh -x -i > > The -x makes it print all the output as it's executing the body of the > test_expect_success rather than suppressing it, and -i makes it stop > as soon as it encounters a failing test, which makes it easier to > examine the state of that test. After the script aborts (via -i), look > inside the "trash*" directory. Also, you can insert calls to > test_pause in the body of a test, which will make it drop into an > interactive shell session in the trash directory at the point of the > test_pause, so you can examine the state of the test directly as it > exists at that point (as opposed to examining it after the test > failed, as with -i). This works fantastically. I'm not sure why `sh -x ./tXXXX-script.sh` doesn't work but `./tXXXX-script.sh -x` does but this makes debugging a lot simpler. The `-i` flag is also super useful here. Appreciated.
