Caleb White <cdwhite3@xxxxx> 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.
