How to re-use setups in multiple tests?

I'm wondering if there's a pattern for re-using setups across several
tests, similar to how a setUp function is used in xUnit. The problem
is I need the setup to actually be re-run, for each test to start from
a clean slate, so using the following doesn't work as the setup is
just run before the first test.

test_expect_success setup '
     # setup repostory to a particular state
'
test_expect_success test1 '
    # some test that expects the state to be as defined in setup, and
changes state of repository
'

test_expect_success test2 '
    # another test that expects the state to be as defined in setup
'

Is there a convention for doing this that's already used? Perhaps
pulling the setup code into a function or duplicating the code? Or is
it better to create a separate test file for tests that need to be
isolated?

Thanks,

-Tom

Hi,

On Mon, 1 Oct 2007, Tom Clarke wrote:

I'm wondering if there's a pattern for re-using setups across several 
tests, similar to how a setUp function is used in xUnit. The problem is 
I need the setup to actually be re-run, for each test to start from a 
clean slate, so using the following doesn't work as the setup is just 
run before the first test.

We typically do the clean up phase explicitely.  Or avoid it.

Example: you want to do something to a branch, but the next step should 
use the original state of the branch.

Solution: "git checkout -b new-branch HEAD~5"

Sorry, unless you are a little less mysterious about the exact use case 
you have in mind, I cannot help more.

Ciao,
Dscho

In this case the first test rebases the branch created in setup (it's
testing the rebase merge strategy), the second test should do the same
thing, except check there is a warning if a --message option is
passed.

I suppose I could find the old pre-rebase head and work with that, but
that doesn't seem that clean to me.

Here's the code (non-working):

#!/bin/sh

test_description='merge-rebase backend test'

. ./test-lib.sh

test_expect_success setup '
        echo hello >a &&
        git add a &&
        test_tick && git commit -m initial &&

        git checkout -b branch &&
        echo hello >b &&
        git add b &&
        test_tick && git commit -m onbranch &&

        git checkout master &&
        echo update >a &&
        git add a &&
        test_tick && git commit -m update
'

test_expect_success 'merging using rebase does not create merge
commit' '
        git checkout branch &&
        git merge -s rebase master &&

        ( git log --pretty=oneline ) >actual &&
        (
                echo "4db7a5a013e67aa623d1fd294e8d46e89b3ace8f
onbranch"
                echo "893371811dbd13e85c098b72d1ab42bcfd24c2db update"
                echo "0e960b10429bf3f1e168ee2cc7d531ac7c622580
initial"
        ) >expected &&
        git diff -w -u expected actual
'

test_expect_success 'merging using rebase with message gives warning'
'
        #doesn't work because the branch has already been rebased and
is therefore up to date
        git checkout branch &&
        git merge -m "a message" -s rebase master 2>&1 expected &&
        (
                echo "warning: Message is not used for rebase merge
strategy"
        ) >expected &&
        git diff -w -u expected actual
'

test_done


-Tom

On 10/1/07, Johannes Schindelin [off-list ref] wrote:

Hi,

On Mon, 1 Oct 2007, Tom Clarke wrote:

quoted

I'm wondering if there's a pattern for re-using setups across several
tests, similar to how a setUp function is used in xUnit. The problem is
I need the setup to actually be re-run, for each test to start from a
clean slate, so using the following doesn't work as the setup is just
run before the first test.

We typically do the clean up phase explicitely.  Or avoid it.

Example: you want to do something to a branch, but the next step should
use the original state of the branch.

Solution: "git checkout -b new-branch HEAD~5"

Sorry, unless you are a little less mysterious about the exact use case
you have in mind, I cannot help more.

Ciao,
Dscho

Hi,

On Mon, 1 Oct 2007, Tom Clarke wrote:

In this case the first test rebases the branch created in setup (it's 
testing the rebase merge strategy), the second test should do the same 
thing, except check there is a warning if a --message option is passed.

I suppose I could find the old pre-rebase head and work with that, but 
that doesn't seem that clean to me.

You can use "git reset --hard master@{1}", and it really escapes me why 
this should not be clean, and why you want to jump through hoops instead 
using a much more complicated technique.

Ciao,
Dscho

On 10/1/07, Johannes Schindelin [off-list ref] wrote:

quoted

I suppose I could find the old pre-rebase head and work with that, but
that doesn't seem that clean to me.

You can use "git reset --hard master@{1}", and it really escapes me why
this should not be clean, and why you want to jump through hoops instead
using a much more complicated technique.

That'll be because my git knowledge isn't good enough to make it
clean. Thanks for the suggestion :-)

-Tom

On 2007-10-01 14:46:46 +0200, Tom Clarke wrote:

On 10/1/07, Johannes Schindelin [off-list ref] wrote:

quoted

quoted

I suppose I could find the old pre-rebase head and work with
that, but that doesn't seem that clean to me.

You can use "git reset --hard master@{1}", and it really escapes
me why this should not be clean, and why you want to jump through
hoops instead using a much more complicated technique.

That'll be because my git knowledge isn't good enough to make it
clean. Thanks for the suggestion :-)

Another even more foolproof way would be to have the setup create a
(lightweight) tag, and let each subtest reset to that tag.

-- 
Karl Hasselström, kha@treskal.com
      www.treskal.com/kalle