git - 我应该如何在 Git 中管理测试工具——它们应该放在单独的仓库中吗？

Question

我现在在 Git 中管理一个大型（ish）项目 [90 个文件 650kb 代码]。我有一些独立的测试工具用于尝试/测试新的低级计算位，这些位后来合并到主代码及其分支中（目前通过复制粘贴！）。

管理测试工具的推荐最佳实践是什么？

它们应该在单独的存储库中，还是应该在主存储库中创建一个空分支来启动它，或者只是创建一个“测试工具”分支并覆盖旧代码？

希望的好处是主分支中的测试代码将与测试的代码明显“相同”。

我在 Windows (msysgit) 上，我是公司中使用 Git 的主要“探索者”。

Answer 1

我在大多数项目中看到的通常结构是包含一个test/与 平行的目录层次结构src/，并将它们存储在那里（在同一个 repo 中）。

Answer 2

文件的数量和大小完全在 git 将所有这些内容保存为一个存储库的能力范围内。即使您将它们提高了一两个数量级。因此，将它们分成两个存储库或将它们保存在一个存储库中的真正原因与易用性有关，而不是 git 的技术限制。

我喜欢将测试保存在与他们测试的代码相同的存储库中。当我更新代码以包含新功能时，我会更新单元测试，让两者同步非常好。

当我添加代码来修复缺陷并添加回归测试时，让两者同步再次很好。

当我检查旧版本时，单元和回归测试与代码同步，我知道捆绑的测试应该全部通过。我可以将任何故障归因于系统中的某些其他组件（例如操作系统或工具更改），这有助于我确定这类事情，而不会干扰猜测哪些测试可能是“预期的故障”。

不利的一面是，如果我发现我的单元测试中缺少某些内容，则很难将其追溯添加到“应该”的位置。但是，我发现在检查去年 4 月的代码是否适用于某些新子系统或其他子系统时，会有很多“猜测可能没问题”失败的较小缺点。

不过，您的权衡可能会有所不同。也许您的管理链没有为在添加新功能时添加大量单元测试提供足够的支持，因此您可能有更高比例的测试需要追溯应用。也许您更擅长通过某些可读属性导出功能更改，并且您的测试集不能运行预期的失败。也许您的测试由与代码不同的组管理。其中任何一个都可能改变平衡。

Answer 3

90 个文件和 650KB 的源代码绝对不算大。最好将测试工具/测试套件等与您的源代码一起保存在同一个存储库中。检查 github 中的一些存储库（例如：PLY）并决定如何组织源代码和测试套件。