Best Git strategy for testing different client and server versions

Question

I would like to be able to run integration tests for a Java client/server (using embedded jetty). In addition I would like to be able to mix-and-match different server and client source code versions during the integration testing.

I am wondering what the best git or maven version strategy to accomplish this:

1. Using the same git repository for the client and the server, it would be difficult to checkout code of various server versions and test it against code of various client versions.

2. Using separate git repositories (1st repository with client src and integration tests, 2nd repository with server src) - It would also require to checkout both repositories to run the integration tests, and assume relative paths between them.

3. Testing the client src code only against maven-version server WAR, may result in honest mistakes of developers running tests against a server WAR that does not match the checked-out server source code.

Answer 1

I'll point out a third challenge: The integration tests may have bugs, so you might wish to control the test version independently as well.

I've used git's submodules feature to coordinate multiple repositories. Create a new repository that will contain references to both the client repo and the server repo. You can place a basic test driver in this parent repo as well.

When a new developer joins the team, they can clone this parent repo, then run git submodule update --init to clone the client and server submodules. That way they'll have any relative paths set up the same way as everyone else.

However, I don't like letting, say, the client repo assume that the server is at ../server/. So the way I've handled this is to let the parent repo pass any needed paths to the submodule. For example, you could have a test.sh in the parent repo that runs

make -C client SERVER_PATH=$(pwd)/server test

In your case, you could also place all the test code in the parent repo. Then it can safely assume relative paths to the submodules.

An interesting side benefit of this arrangement: You can create git commits that record specific combinations of versions, because the version that's checked out in the submodule is recorded when you commit in the parent repo. You might use that to create a branch or a collection of tags for version combinations that have passed your tests.