Max*_*ini 3 unit-testing test-data
这个问题的副产品.你把它们放在源代码树里吗？你把它们保存在源代码管理中吗？
我想如果你的测试用例引用文件,那么文件是系统行为规范的一部分,因此它们与系统的当前版本相关联,因此它们应该被检查到源代码控制中.但是我不认为它们应该在本地签出,因为它们不需要,并且它们可能非常大.所以我倾向于使用并行树,这样如果项目的代码文件位于$ svn/Code/foo/bar/baz,则相关的测试数据文件位于$ svn/TestData/foo/bar/baz中,并且后者将直接从服务器访问使用某种常见的测试数据助手类(可能在本地缓存文件？),这可以只接受相对路径并找出在哪里找到它们.这有意义吗？
我想有一个相关的问题,即我应该在多大程度上使用外部文件进行测试.我认为它们通常适用于更高级别的"验收"测试.
我们订阅了"一切都在源头控制下"的思想流派(肛门保留甚至没有开始描述我们).
这意味着我们负责的所有级别测试的测试用例(代码和数据)(单元,系统,集成,翻译......),开发软件CD/DVD映像,操作系统映像,测试环境的VM,所有doco,如果团队中的所有PC和软件都被盗,基本上是将开发/测试环境整合在一起所需的一切 - 除了硬件,但这只是因为我们还没有办法检查它: - ).
磁盘空间比重新获取我们需要的所有东西要便宜得多.当一个版本的软件发布到野外时,我们实际上会检查构建该版本所需的所有内容,将其刻录到多个DVD并在原始硬件上测试该过程.然后我们制作多份副本并将其分发到宇宙的四个角落......哎呀,抱歉,被带走了.
但我们确实做了我所说的一切,尽管构建DVD分布在多个地理上分开的位置(在地球上,而不是在整个宇宙中).
至于它在源代码控制树中的位置,我们树的顶层始终是一个版本,那个版本的所有内容都存在于那里.这提供了大量的重复,但使事情变得非常容易管理.而且,通常,磁盘存储比人力资源便宜很多.
| 归档时间： |
|
| 查看次数： |
1230 次 |
| 最近记录： |