Question

this问题的分拆。你把它们放在源代码树里吗？你把它们保存在源代码管理中吗？

我在想如果您的测试用例引用文件，那么这些文件是系统行为规范的一部分，因此它们与系统的当前版本相关联，因此应将它们检入源代码管理中。但我不认为它们应该在本地签出，因为它们不需要，并且它们可能非常大。所以我倾向于使用并行树，这样如果项目的代码文件位于$ svn / Code / foo / bar / baz，则相关的测试数据文件位于$ svn / TestData / foo / bar / baz中，并且后者将直接从服务器访问使用某种常见的测试数据助手类（可能在本地缓存文件？），这可以只接受相对路径并找出在哪里找到它们。这有意义吗？

我想有一个相关的问题，即我应该在多大程度上使用外部文件进行测试。我认为它们通常适用于更高级别的“验收”测试。

Answer 1

我们订阅了“一切都在源头控制下”的思想流派（肛门保留甚至开始来形容我们）。

这意味着我们负责的所有级别测试的测试用例（代码和数据）（单元，系统，集成，翻译......），开发软件CD / DVD映像，操作系统映像，用于测试的VM环境，所有doco，基本上所有，如果团队中的所有PC和软件都被盗，那么将开发/测试环境整合在一起需要 - 除了硬件，但这只是因为我们没有'找到了一种方法来检查它： - ）。

磁盘空间比重新获取所需内容所需的时间便宜得多。当一个版本的软件发布到野外时，我们实际上会检查构建该版本所需的所有内容，将其刻录到多个DVD并在原始硬件上测试该过程。然后我们制作多份副本并将其分发到宇宙的四个角落......哎呀，抱歉，被带走了。

但我们做做我所说的一切，尽管构建DVD分布在多个地理上分开的位置（在地球上，而不是在整个宇宙中）。

至于它在源代码控制树中的位置，我们树的顶层始终是一个版本，那个版本的所有内容都存在于那里。这提供了大量的重复，但使事情变得非常容易管理。而且，通常，磁盘存储比人力资源便宜很多。

Answer 2

但我不认为他们应该在本地签出，因为他们不需要

为什么不呢？测试是任何复杂软件系统的组成部分。如果他们没有他们的数据就无法运行，那么他们就变得毫无用处。

在需要时远程获取测试数据的想法很有趣，但是当您需要做的就是运行测试时，您将变得依赖于与Subversion服务器的连接。我认为这会给应该做的简单事情带来不必要的复杂性;运行测试永远不应成为开发的瓶颈。

除此之外，您可能还需要考虑以下事实：您现在必须维护两个不同的svn树。当您有多个功能分支和版本或标签时，这可能会成为一场噩梦。

为明确回答您的问题，我们将测试文件保存在＆lt; project root＆gt; / tests中，以便每个分支都有自己的一组工作和有用的测试。

Answer 3

我绝对认为测试数据应该在与测试和源相同的树中进行版本控制，以便轻松下载最新代码并运行测试。我像这样设置树木：

trunk/
  +- Source/
  +- TestSource/
  \- TestData/

测试然后引用../TestData/myTestData.xml或他们需要的任何东西。

Answer 4

我以这种方式将它们添加到源代码管理中

- Trunk
     - Source
     - Lib
     - Tests
         - DescriptiveTestName_1
         - DescriptiveTestName_2
- Branches
     - v0.9
         - Source
         - Lib
         - Tests

这样，每个版本的所有文件源，库和测试都在一起，并且在开发（和修复问题）时很容易掌握。测试中的每个子目录都包含测试所需的所有文件。

你在哪里保存测试数据文件？

4 个答案: