6

我希望能够为 Java 客户端/服务器（使用嵌入式码头）运行集成测试。此外，我希望能够在集成测试期间混合匹配不同的服务器和客户端源代码版本。

我想知道完成此任务的最佳 git 或 maven 版本策略是什么：

  1. 客户端和服务器使用相同的 git 存储库，很难检查各种服务器版本的代码并针对各种客户端版本的代码对其进行测试。

  2. 使用单独的 git 存储库（具有客户端 src 和集成测试的第一个存储库，具有服务器 src 的第二个存储库） - 它还需要检出两个存储库以运行集成测试，并假设它们之间的相对路径。

  3. 仅针对 maven-version 服务器 WAR 测试客户端 src 代码，可能会导致开发人员针对与签出的服务器源代码不匹配的服务器 WAR 运行测试时出现诚实错误。

4

2 回答 2

4

我将指出第三个挑战：集成测试可能存在错误，因此您可能还希望独立控制测试版本。

我使用 git 的子模块功能来协调多个存储库。创建一个新的存储库，其中将包含对客户端存储库和服务器存储库的引用。你也可以在这个父仓库中放置一个基本的测试驱动程序。

当新的开发人员加入团队时，他们可以克隆这个父 repo，然后运行git submodule update --init克隆客户端和服务器子模块。这样他们就可以像其他人一样设置任何相对路径。

但是，我不喜欢让客户端 repo 假设服务器位于../server/. 所以我处理这个问题的方式是让父 repo 将任何需要的路径传递给子模块。例如，您可以test.sh在运行的父存储库中有一个

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

在您的情况下，您还可以将所有测试代码放在父仓库中。然后它可以安全地假设子模块的相对路径。

这种安排的一个有趣的附带好处是：您可以创建记录特定版本组合的 git 提交，因为在子模块中签出的版本会在您提交到父 ​​repo 时记录。您可以使用它为已通过测试的版本组合创建一个分支或一组标签。

于 2012-11-11T21:21:56.373 回答
1

I suggest keeping the process simple, as you have enough variables going on already without introducing potential git management issues. To that end, I would avoid submodules. I would instead give the developers clear pairings of branches/tags to test for both the client and server repos in your testing matrix.

Use tags so you can more easily reuse and repeat the same tests in your matrix again in the future, especially after bugs have been fixed from the first round.

In short, I recommend your solution #2. The relative paths assumption is preferable to the potential confusion introduced by submodules.

于 2012-11-17T15:39:59.663 回答