我正在慢慢地对我的常规工作流进行git和unit testing部分测试。我很感激关于单元测试框架（不是测试本身，而是实际框架）是否应该包含在项目的git仓库中的建议。一方面，它看起来不应该，因为框架是a）在其他地方容易获得的，b）对项目来说不是唯一的（我正在讨论流行的框架，比如qunit for JS或PHP中的simpletest） 。在这种情况下，在回购中可能有一个简单的自述文件，指出框架的版本以及在哪里获得它就足够了。在git repo中包含测试框架？
另一方面，测试是项目的一部分（也是回购的一部分），并且确实需要运行框架，所以为了完整性，也许应该包括框架？
谢谢。
阅读这个问题的答案很有意思，因为它显示了对软件开发许多不同方面的非常广泛的解释。我通常认为任何类型的依赖关系都不应该存储在VCS中（通过VCS，我指的是像git，hg，svn，cvs这样的工具，而不是像Xcode那样包含这些工具的更大的系统），因为这是而不是VCS的工作。依赖性跟踪最好留给打包工具。 （看起来很多人使用VCS作为原始包装工具，恕我直言，这是一个巨大的错误。）
我想你需要澄清你的意思是'测试框架'。对我而言，我的大多数测试套件都是由automake提供的框架调用的。我当然不会在我的git仓库中包含automake，但未来版本差异没有问题，因为automake生成的所有测试框架都包含在分发tarball中。所以真正的问题是推回到一个更高的水平。如果您仅使用VCS来跟踪您的版本，那么您遇到了问题，因为您确实需要在检出旧版本的项目时使测试框架可用。如果VCS是检索旧版本的唯一存储机制（即，您未在tarball中使用任何排序存档版本），那么您似乎不得不将该框架放入VCS中。但坦率地说，将外部软件放入VCS是很愚蠢的。这样做的唯一原因是如果您使用VCS作为您的分发工具。所以我想我的答案是：不要把框架放到你的VCS中，但是把框架放在你的发行版中。如果你的VCS是你的分布工具，那么没有正确的方法来处理测试框架。
我会说不，因为它们很容易在别处找到，而且任何有经验的开发人员都应该已经有了这些库。另外，一些现代的IDE（特别是eclipse）已经提供了你需要的单元测试库，所以将它们与你的源一起发布并不重要。
我几乎总是包含框架（一个理智的应该是几个库和可执行文件，所以不是那么大） - 源代码和测试版本化，如果我回去从2001年获取我的代码的1.2版本，我希望在进行修复时运行测试 - 不要失败，因为我使用的是2006年更改为的测试框架。
没有源代码控制中的测试框架，我添加了一件事匹配版本。哎呀，如果可行的话，我会在那里版本编译器和语言库。
如果你有一个巨大的测试工具/平台不能轻易放在一起（或者不能合法地放在一起），请确保包含某种类型的文档以告知哪些工具，哪些版本，并可能如何将它与测试结合在一起。
有趣的问题。尽管如此，我认为测试框架不应该包含在应用程序库中。
在自述文件中命名项目的先决条件。如果您有多个使用相同测试框架的项目，那么您已经安装了该框架，并且您可能不希望为每个项目再次下载或安装该框架。
我使用单元测试在我的所有仓库中包含NUnit DLL。我实际上包含了我需要编译和运行测试的所有知识库。当然，这对于一些项目来说是不可行的，但是如果可行的话，检查仓库并开始工作变得非常容易。无需安装。
不，你不应该在你的仓库中包含外部框架，除非你实际上修改框架来处理你的项目。
根据您使用的是什么语言，您可能需要使用README文件或依靠您的打包工具;例如，Python的distutils和Perl的Module :: Build都允许指定运行测试所需的外部模块，并且会为用户安装依赖关系。
我们将全部引用库到我们的存储库。
这样做的好处是您可以将所有必需的组件放在一个位置。如果你有一台新电脑，你只需要安装你选择的IDE，检出版本库，并且你已经准备好了。
这也使得构建服务器上的构建过程变得很容易，因为您只需将其指向存储库即可，该存储库包含构建所需的所有内容（尽管使用.NET框架）。因此很容易创建一个没有任何版本问题的旧版本版本。
从Python世界中，我会将依赖关系包含在我的setup.py文件中。开发人员可以获取它们。
有了tarball，我有时会包含一个generated test file ，这样人们在运行项目之前至少可以做一些健康测试。
VCS与分销/包装之间的区别很有趣，而且我之前没有真正听说过。我认为这种区分捕捉到了我一直在努力的模糊性，所以我将其标记为答案，即使我认为许多其他答案也很好。 – 2011-04-08 16:00:49