2009-08-03 82 views
2

问题分类的分拆this。你把它们放在源代码树中吗?你让他们在源代码控制?你在哪里保存你的测试数据文件?

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

我想这里有一个相关的问题,我应该如何广泛地使用外部文件进行测试。我认为他们通常对更高级别的“接受”测试有好处。

回答

3

但我不认为他们应该在本地查出来,因为他们并不需要是

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

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

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

要明确回答您的问题,我们将我们的测试文件保存在<项目根目录>/tests中,以便每个分支都有自己的一组工作和有用的测试。

+0

是的,我明白你在说什么。我想在低级单元测试和高级验收测试(可能包括性能测试方面并在某些情况下在多千兆字节的输入数据上运行)之间需要进行清晰的分割?很明显,我不应该在每次进行更改时都运行后者,因为他们需要几分钟的时间才能运行,但我仍然希望以某种方式定期自动运行它们。 正如你所看到的,我对于如何处理这样的项目的测试仍然有些困惑,这些项目旨在处理大量和杂乱的数据输入。 – 2009-08-03 04:11:55

0

我将它们添加到源代码控制这样

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

这样,所有文件的源,库和测试是为每个版本,并很容易起床的速度发展时,(和修复问题)。测试下的每个子目录都包含测试所需的全部文件。

+0

然后“测试”包含测试数据文件以及测试的源代码吗?或者是Source/test下的源代码? – MatrixFrog 2009-08-03 03:39:54

6

我们订阅“源代码控制下的所有东西”学派(肛门保留甚至没有开始来形容我们)。这意味着我们负责的所有测试级别(单元,系统,集成,翻译...),开发软件CD/DVD映像,操作系统映像,VM的测试用例(代码和数据)测试环境,所有的doco,基本上所有,如果团队中的所有PC和软件都将被盗用,将需要将开发/测试环境放在一起 - 除了硬件,但那只是因为我们还没有找到方法检查它在:-)。

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

但我们尽我所说尽管构建DVD分布到多个地理位置分开的位置(在这个星球上,而不是在整个宇宙)。

至于它在源代码控制树中的位置,我们树的顶层始终是一个版本,与该版本相关的一切都存在于此。这给了大量的重复,但使事情变得非常容易管理。而且,通常情况下,磁盘存储比人力资源便宜很多。

1

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

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

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