2010-04-07 94 views
9

我对以下方案特别感兴趣。假设您有编写生产代码的团队和编写自动测试的团队。编写自动测试的团队有专门的框架来编写自动测试。测试团队是否应该为其框架编写单元测试,尽管该框架未用于生产?你对非生产代码进行单元测试吗?

回答

4

我已经在这种情况下,什么我所做的是使用测试套件产品代码也可作为测试套件的测试框架。据推测,该框架的所有功能都是实际使用的,所以如果测试失败而没有更改生产代码,那么测试框架中必定存在问题。

它工作正常 - 运行这些测试花费的时间比专用测试测试套件要长得多,有时我不会运行所有这些测试,并且在生产构建服务器上出现问题。诊断这些问题花费的时间比测试测试套要长得多。总而言之,我从来没有对它感到满意,并且真的会推荐为测试框架进行专门的测试。从测试团队的角度来看,测试框架的产品代码是。如果测试框架被任何其他人使用,其测试套件无法访问...

1

是的,如果只是为了测试框架产生足够的测试覆盖率。

4

地狱是!

TDD为您提供开发优势,不仅仅是为了取悦客户。它允许你编写可测试的,可重用的和模块化的代码。我会单元测试一切必须工作的东西,特别是如果您希望经常更改它(重构添加新功能)。

2

测试团队应该尽一切可能增加他们对框架所提供结果的信任。

这包括测试,代码审查,质量标准,...

0

这个问题让我想起了一个故事:曾几何时有一家公司。该公司相信自动测试。这种信念如此强烈,导致创建一个团队,其唯一目的就是编写这些自动测试。所有最热心的信徒都被允许加入这个组织。有很多欢乐!

然后有一天,发现这个自动测试组尽管有其使命,但并没有为自己的工作使用自动测试。石头铸造,亚达亚达。


我只是说...我认为任何测试框架都会有非常稳定的测试覆盖率。

+0

你可以这样看我的问题。但是我认为根据这个论点决定测试非生产代码是天真的。维护测试最终会花钱,而且我个人认为您应该只测试自动化框架,而不是测试自动化实验室的每一个位置。另一方面,在生产代码中,您的目标是尽可能多地进行测试。这是我的问题的原因。 – Ikaso 2010-04-11 07:35:04

+0

我正在翻转,但我的观点是可以应用相同的评估标准。为什么我们编写自动化测试,即使他们可能会将开发成本增加15%? 最后,答案是_因为它增加了我们对code_的信心。这不是黑色和白色 - 问题是我们应该再写1个测试吗?如果我们已经对代码有信心,或者信心不是那么重要,那么就没有必要编写测试。无论软件的消费者是商业客户,开发人员还是我的小弟弟,我都会遵循该指南。 – ndp 2010-04-11 15:23:34

相关问题