4

有点像这个问题的副产品。您是否将它们保留在源代码树中?您是否将它们保留在源代码控制中?

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

我想有一个相关的问题是我应该首先使用外部文件进行测试的范围。我确实认为它们通常适用于更高级别的“验收”测试。

4

4 回答 4

7

我们赞同“一切都在源头控制之下”的思想流派(肛门保留甚至没有开始描述我们)。

这意味着我们负责的所有测试级别(单元、系统、集成、翻译……)的测试用例(代码和数据)、开发软件 CD/DVD 映像、操作系统映像、用于测试环境的 VM 等等doco,基本上,如果团队中的所有 PC 和软件都被盗,则将开发/测试环境组合在一起所需的一切——硬件除外,但这只是因为我们还没有找到一种方法来检查它 -)。

磁盘空间比重新获取我们需要的一切所需的时间要便宜得多。当一个版本的软件发布到野外时,我们实际上检查了构建该版本所需的一切,将其刻录到多张 DVD 并在原始硬件上测试该过程。然后我们制作多个副本并将其分发到宇宙的四个角落……哎呀,对不起,走神了。

但是我们确实做了我所说的一切,尽管构建 DVD 分发到多个地理上分开的位置(在地球上,而不是在整个宇宙中)。

至于它在源代码控制树中的位置,我们树的顶层始终是一个版本,与该版本有关的所有内容都存在于那里。这会产生大量重复,但会使事情变得非常容易管理。而且,一般来说,磁盘存储比人力资源便宜得多。

于 2009-08-03T03:50:19.923 回答
4

但我认为它们不应该在本地检查,因为它们不需要

为什么不?测试是任何复杂软件系统的组成部分。如果他们无法在没有数据的情况下运行,那么他们将变得毫无用处。

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

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

为了明确回答您的问题,我们将测试文件保存在 <project root>/tests 中,以便每个分支都有自己的一组有效且有用的测试。

于 2009-08-03T03:53:24.643 回答
1

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

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

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

于 2009-08-03T03:55:11.177 回答
0

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

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

这样,每个版本的所有文件源、库和测试都在一起,并且在开发(和修复问题)时很容易加快速度。测试下的每个子目录都包含测试所需的所有文件。

于 2009-08-03T03:38:28.260 回答