我正在慢慢地对我的常规工作流程进行git和单元测试。我很欣赏有关单元测试框架(不是测试本身,而是实际框架)是否应该包含在项目的git仓库中的建议。
一方面,它似乎不应该,因为框架是a)在别处可以随时使用; b)不是项目独有的(我在谈论流行的框架,例如JS的qunit或PHP中的simpletest)。在这种情况下,或许repo中的一个简单的自述文件指示框架的版本以及在何处获取它就足够了。
另一方面,测试是项目的一部分(和repo的一部分),并且确实需要运行框架,所以为了完整起见,也许框架也应该被包括在内?
感谢。
答案 0 :(得分:3)
我几乎总是包含框架(一个理智的应该是一些库和可执行文件,所以不是那么大) - 源和测试是版本化的,如果我从2001年返回并获得我的代码的1.2版,我想在运行该修补程序时运行测试 - 不要失败,因为我使用的是我在2006年更改的测试框架。
如果没有源代码管理中的测试框架,我还需要添加一个匹配版本的东西。哎呀,如果可行,我还会在那里对编译器和语言库进行版本化。
如果你有一个巨大的测试工具/平台,不能轻易放入(或不能合法地放在一起),请确保你包含一个告诉什么工具,什么版本,并且可能如何将它与测试结合起来。
答案 1 :(得分:2)
阅读这个问题的答案很有意思,因为它展示了对软件开发的许多不同方面的广泛解释。我通常认为任何类型的依赖都不应该存储在VCS中(通过VCS,我指的是像git,hg,svn,cvs这样的工具,而不是包含这些工具的大型系统,比如Xcode),因为那是不是VCS的工作。依赖性跟踪最好留给包装工具。 (似乎很多人使用VCS作为原始包装工具,恕我直言是一个巨大的错误。)
我认为您需要澄清“测试框架”的含义。对我来说,我的大多数测试套件都是由automake提供的框架调用的。我当然不会在我的git存储库中包含automake,但是将来版本差异没有问题,因为automake生成的所有测试框架都包含在分发tarball中。所以这个问题真的被推回了一个层次。如果您只使用VCS来跟踪您的版本,那么您就会遇到问题,因为在签出旧版本的项目时,您确实需要提供测试框架。如果VCS是唯一用于检索旧版本的存储机制(即,您没有在tarball中使用任何排序版本的存档),那么您似乎被迫将框架放入VCS中。但坦率地说,将外部软件放入VCS中是件事。这样做的唯一原因是您使用VCS作为分发工具。所以我想我的答案是:不要将框架放在您的VCS中,而是将框架放在您的发行版中。如果您的VCS是您的分发工具,则没有正确的方法来处理测试框架。
答案 2 :(得分:1)
有趣的问题。我不认为测试框架应该包含在应用程序存储库中。
在自述文件中命名项目的先决条件。如果您有多个使用相同测试框架的项目,那么您已经安装了框架,并且您可能不希望为每个项目再次下载或安装它。
答案 3 :(得分:1)
我通过单元测试在我的所有存储库中包含NUnit DLL。我实际上在存储库中包含了编译和运行测试所需的所有内容。当然,对于某些项目来说这是不可行的,但是当它可行时,只需检查存储库并开始工作就变得非常容易。无需设置。
答案 4 :(得分:1)
我们将所有引用的库添加到我们的存储库中。
这样做的好处是,您可以在一个地方拥有所有必需的组件。如果您有一台新计算机,只需安装您选择的IDE,检查存储库即可。
这也使得在构建服务器上启动构建过程变得容易,因为您只需将其指向存储库,其中包括构建所需的所有内容(尽管使用.NET框架)。因此,在没有任何版本问题的情况下创建旧版本的构建很容易。
答案 5 :(得分:0)
我会拒绝,因为它们随处可用,任何有经验的开发人员都应该已经可以随时使用这些库。
此外,一些现代IDE(特别是eclipse)已经附带了您需要的单元测试库,因此发布带有源代码的库并不重要。
答案 6 :(得分:0)
不,您不应该在您的仓库中包含外部框架,除非您实际修改框架以使用您的项目。
根据您使用的语言,您可能希望使用自述文件或依赖您的打包工具;例如,Python的distutils和Perl的Module :: Build都允许指定运行测试所需的外部模块,并为用户安装依赖项。
答案 7 :(得分:0)
在Python世界中,我将依赖项包含在setup.py
文件中。开发人员可以随后获取它们。
使用tarball,我有时会包含generated test file 这样人们在运行项目之前至少可以做一些健全测试。