Re: Question re testing configuration

From: Jeff King <peff@peff.net>
Date: Apr 27, 2017, 05:18 UTC
Message-ID: <20170427051850.kb77hy64ttsr46cs@sigill.intra.peff.net>
In-Reply-To: <CAJZjrdWPezo6=JHcp9mp8C5Pm1uJodSj3Mbgn7ix78MAqpUUXw@mail.gmail.com>

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

Show 17 quoted lines

> 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