文件的数量和大小完全在 git 将所有这些内容保存为一个存储库的能力范围内。即使您将它们提高了一两个数量级。因此,将它们分成两个存储库或将它们保存在一个存储库中的真正原因与易用性有关,而不是 git 的技术限制。
我喜欢将测试保存在与他们测试的代码相同的存储库中。当我更新代码以包含新功能时,我会更新单元测试,让两者同步非常好。
当我添加代码来修复缺陷并添加回归测试时,让两者同步再次很好。
当我检查旧版本时,单元和回归测试与代码同步,我知道捆绑的测试应该全部通过。我可以将任何故障归因于系统中的某些其他组件(例如操作系统或工具更改),这有助于我确定这类事情,而不会干扰猜测哪些测试可能是“预期的故障”。
不利的一面是,如果我发现我的单元测试中缺少某些内容,则很难将其追溯添加到“应该”的位置。但是,我发现在检查去年 4 月的代码是否适用于某些新子系统或其他子系统时,会有很多“猜测可能没问题”失败的较小缺点。
不过,您的权衡可能会有所不同。也许您的管理链没有为在添加新功能时添加大量单元测试提供足够的支持,因此您可能有更高比例的测试需要追溯应用。也许您更擅长通过某些可读属性导出功能更改,并且您的测试集不能运行预期的失败。也许您的测试由与代码不同的组管理。其中任何一个都可能改变平衡。