0

Let say I've previously set up a super-swish test framework for a legacy system. That is feature A existed long before the test for feature A. Feature B, C and D come along and without us realising, at some point break the test for feature A.

We want to find out which of the features did that.

Now I want to run:

git bisect <bad> <good>
git run ./swish_test_suite.sh

The issue is that the code files that test feature A came in between <bad> and <good>. I've tried just manually extracting out the code, but then various configurations, and paths to test data break (fragile code?).

Is there a way to tell git bisect to ignore a folder? I can imagine that going horribly wrong sometimes, but I'm guessing that might be easier than alternatives.

It's not solved here How can I ignore a directory when doing a Git bisect? as that covers build folders, where the solution is to remove them from the repo, but I want to keep my tests commited!

This git bisect with feature branches / later commits are needed to build is a little different too, as I'm not using patches or feature branches (should I?) Also the solutions seem to just be for manually running it, not git bisect running it!

Community
  • 1
  • 1
AncientSwordRage
  • 7,086
  • 19
  • 90
  • 173

1 Answers1

1

For cases like this, write your test script in such a way that it adds stuff that you need in each step. The git help bisect manual has an example which you might be able to tweak to your needs. I.e., where that example does a git merge hotfix, do whatever you need to get the test files you require. Depending on the situation, a merge may not be what you're looking for, but you might cherry-pick your tests from somewhere, or simply copy them to some other directory beforehand (before the bisect operation) and copy them in with cp.

   ·   Automatically bisect with temporary modifications (hot-fix):

           $ cat ~/test.sh
           #!/bin/sh

           # tweak the working tree by merging the hot-fix branch
           # and then attempt a build
           if      git merge --no-commit hot-fix &&
                   make
           then
                   # run project specific test and report its status
                   ~/check_test_case.sh
                   status=$?
           else
                   # tell the caller this is untestable
                   status=125
           fi

           # undo the tweak to allow clean flipping to the next commit
           git reset --hard

           # return control
           exit $status
AnoE
  • 8,048
  • 1
  • 21
  • 36
  • This is great, I think copying to a temp folder and back again would have worked in my example. When I say not using branches, I branch and merge often, so I end up with a very linear history. It looked like in the example they had a long running branch called `test`, which I don't have. – AncientSwordRage Aug 03 '16 at 09:19