Caleb White [off-list ref] writes:
What's the best way to parameterize the worktree tests? I would like
to run the same tests for both absolute and relative paths and I'm
not particularly a fan of just copying them all into new *-relative.sh
files.
What I meant by interoperability tests are a lot smaller scale.
A test that creates worktree/repository pair without the option to
use relative, and then tries to use such a worktree/repository pair
with the option would simulate "how well the newer Git handles an
existing repository", and another test that creates with the option
to use relative and uses the worktree/repository without the option
would simulate "how well existing versions of Git works when seeing
a worktree made with the newer git with the relative option".
By "parameterise", if you mean running a set of worktree/repository
tests without the "relative" option enabled, and run the same set of
tests with the option enabled, you could model it after how t8001
and t8002 (or t5560 and t5561) share a lot of same tests that are in
a file that is included by both of them. In smaller scale, it is
common to have an ad-hoc construct like:
for conf in relative absolute
do
test_expect_success ...
test_expect_success ...
test_expect_success ...
done
that has bunch of test_expect_success, which may change the
behaviour depending on the value of $conf, not &&-chained inside the
for loop. You can use a nested loop (one for preparing, the other
for testing the use of worktree) if you want to test the full
matrix.
I do not offhand know if such parametralized tests are necessary in
the context of this change, though.
Thanks.
Caleb White cdwhite3@pm.me writes:
quoted
What's the best way to parameterize the worktree tests? I would like
to run the same tests for both absolute and relative paths and I'm
not particularly a fan of just copying them all into new *-relative.sh
files.
What I meant by interoperability tests are a lot smaller scale.
A test that creates worktree/repository pair without the option to
use relative, and then tries to use such a worktree/repository pair
with the option would simulate "how well the newer Git handles an
existing repository", and another test that creates with the option
to use relative and uses the worktree/repository without the option
would simulate "how well existing versions of Git works when seeing
a worktree made with the newer git with the relative option".
By "parameterise", if you mean running a set of worktree/repository
tests without the "relative" option enabled, and run the same set of
tests with the option enabled, you could model it after how t8001
and t8002 (or t5560 and t5561) share a lot of same tests that are in
a file that is included by both of them. In smaller scale, it is
common to have an ad-hoc construct like:
for conf in relative absolute
do
test_expect_success ...
test_expect_success ...
test_expect_success ...
done
that has bunch of test_expect_success, which may change the
behaviour depending on the value of $conf, not &&-chained inside the
for loop. You can use a nested loop (one for preparing, the other
for testing the use of worktree) if you want to test the full
matrix.
I do not offhand know if such parametralized tests are necessary in
the context of this change, though.
Thanks.
Ah, I see what you mean, thank you for the details! I'll be sure to
look at the examples and try to determine which would be the best
paths forward.
existing repository", and another test that creates with the option
to use relative and uses the worktree/repository without the option
would simulate "how well existing versions of Git works when seeing
a worktree made with the newer git with the relative option".
I can already tell you that this particular case is not going to work
because existing versions of git expect the path to be absolute. Most
of the changes in this patch revolve around properly reading/handling
the relative paths, not writing the relative paths.
Best,