我应该在哪里存储测试数据?


9

我有一些较小的单元测试,它们使用真实数据集中的小片段。由于多种原因,我还想针对完整的数据集测试我的程序。唯一的问题是单个真实数据集约为5GB。我还没有找到关于Git存储库可以存储的任何硬数字,但这似乎太多了。

根据该程序员的帖子,我应该将测试项目所需的所有数据保留在存储库中。

我的团队采用的解决方案是该项目具有一个文件,该文件包含指向包含我们的测试数据的网络连接文件系统的路径。该文件被Git忽略。

我觉得这是一个不完善的解决方案,原因有两个。当NAS无法正常工作,运行缓慢或出现故障时,我们将无法进行全面测试。第二个原因是,当某人第一次克隆存储库时,单元测试失败,因此他们必须弄清楚如何使用特定名称挂载事物以及用于构建测试路径文件的语法。

所以我的问题有两个。多少数据就是太多数据无法存储在修订控制中?

什么是处理大量测试数据的更好方法?


1
测试数据可能多久更改一次?
罗伯特·哈维

它可能永远不会改变,但随着我们修补错误或添加功能,可能会添加更多数据。
AlexLordThorsen 2014年

1
此处探讨了一些折衷方法:stackoverflow.com/q/984707
Robert Harvey

1
无论git持有什么,您是否都认为从实时数据中获得的完整数据集不是测试数据集(旨在测试成功和失败状态)的观点,仅此一个可能就很重要仓库之外?
James Snell 2014年

单元测试不应使用太多数据。可以想象集成测试可能会。
raptortech97

Answers:


9

如何处理构建链中的大文件

我喜欢使用进行依赖管理的构建工具-例如maven或gradle。文件存储在Web存储库中,该工具在遇到依赖项时会自动进行下载和缓存。它还为想要运行测试的人员消除了额外的设置(NAS配置)。而且,刷新数据变得相当轻松(已版本化)。

太大而无法进行版本控制

有一个很大的灰色区域。而且,如果您确定某些不属于RCS的产品,您有什么选择?如果您将选择限制在RCS和二进制存储库(Maven样式)之间,这是一个更容易的决定。

理想情况下,您只需要人为可编辑,可更改的RCS内容,或想要跟踪历史记录的地方。绝对不是构建或其他某种自动化产品的结果。大小是一个约束,但不是主要的约束-巨大的源文件(不好的做法)肯定属于源控件。一个很小的编译二进制文件没有。

准备妥协以方便开发人员。


3

当NAS无法正常工作,运行缓慢或出现故障时,我们将无法进行全面测试。

显然,这只能通过将5GB从NAS复制到本地驱动器来解决。但是,无需手动执行此操作。

第二个原因是,当某人第一次克隆存储库时,单元测试失败,因此他们必须弄清楚如何使用特定名称挂载事物以及用于构建测试路径文件的语法。

您可以提供一个简单的shell脚本来执行此操作-使用特定名称挂载NAS,然后将数据复制到本地驱动器(如果本地驱动器尚不存在)或NAS上的数据集比本地数据集新时将其复制到本地驱动器。确保脚本将在单元测试的初始化阶段自动运行。

当然,如果不仅有这些数据集之一,而且对源代码存储库之外的外部文件有大量依赖关系,那么@ptyx所提到的工具可能是更好的解决方案。


3

...当某人第一次克隆存储库时,单元测试失败,因此他们必须弄清楚如何使用特定名称挂载事物以及用于构建测试路径文件的语法。

首先,只是为了具有一致的术语:这种测试(大的外部依赖项,真实​​数据)通常不被认为是单元测试,而是集成或系统测试

在实践上,我认为将单元测试和集成测试分开是一个好习惯,因为它们具有不同的优势和劣势。

  • 将代码中的两种测试分开(命名约定,单独的项目...)
  • 提供仅运行两种测试套件之一的方法
  • 在正常构建期间仅运行单元测试
  • 根据需要在CI(连续集成)服务器上运行集成测试

这样,本地构建既快速又可靠(几乎没有外部依赖),并且集成测试由功能强大的CI服务器处理。这样可以避免您描述的问题。

关于如何保存数据:

一个不错的选择是某种工件管理,例如ptyx的答案描述。另一个方法是将测试数据放入单独的存储库中。无论如何,数据不会与主版本一起发布,并且具有单独的回购可避免强迫每个人随源代码获取测试数据。换句话说,使用第二个存储库作为您的artifacdt管理:-)。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.