Re: Question re testing configuration

On Wed, Apr 26, 2017 at 10:56:23PM -0500, Samuel Lijin wrote:

I *know* that the changes I'm working on are causing the tests to
fail, but I can't figure out how to induce the failure manually (so
that I can throw gdb at the problem).

Specifically I'm seeing t5000-tar-tree.sh fail (as a result of adding
extra diff_populate_filespec() calls before the estimate_similarity()
loop in diffcore_rename()) on #52 "set up repository with huge blob"
and #55 "set up repository with far-future commit".

If I run the commands fed into test_expect_success in t5000, though
(in an empty repo initialized with git init), making sure to use the
binary compiled with the breaking changes, the command doesn't fail,
so I'm clearly missing something in the testing environment setup when
I try to manually reproduce it.

Can someone point me in the right direction? I've spent some time now
going through t/test-lib.sh and I haven't figured it out yet.

I'd usually start by stopping the script at the failed test, going into
the repository directory, and then running from there. Like:

  $ cd t
  $ ./t5000-tar-tree.sh -v -i -x
  $ cd trash\ directory.t5000-tar-tree
  $ gdb --args ../../git whatever-failed

That's usually enough to re-create the broken state. Sometimes there are
things in the environment, or the test is impacted by your user-level
config (test-lib resets $HOME, so it should have no user config). But
it's usually easier to just stick a "gdb" temporarily into the test.
Note there are some tricks there with redirections and the bin-wrappers
script; see the debug() helper in test-lib-functions.sh.

-Peff