Question re testing configuration

Samuel Lijin· Apr 27, 2017, 03:56 UTC · lore

Hi all,

I'm a new developer trying to get my feet wet and I'm running into an issue with the tests that I can't figure out at this point.

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.

Thanks, Sam

Jeff King· Apr 27, 2017, 05:18 UTC · re: Samuel Lijin · lore

Re: Question re testing configuration

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