13

在进行TDD时,如何判断“对于此类/功能的测试已经足够了”?

即你什么时候可以告诉你完成了所有边缘情况的测试?

4

13 回答 13

13

使用测试驱动开发,您将在编写测试代码之前编写测试。编写完代码并且测试通过后,就该编写另一个测试了。如果你正确地遵循了 TDD,那么一旦你的代码完成了所有需要的测试,你就已经编写了足够多的测试。

至于边缘情况,我们举一个例子,比如验证方法中的参数。在将参数添加到代码之前,您需要创建测试来验证代码将正确处理每种情况。然后您可以添加参数和关联的逻辑,并确保测试通过。如果您想出更多边缘情况,则可以添加更多测试。

通过一步一步来,您在编写完代码后就不必担心边缘情况,因为您已经为所有情况编写了测试。当然,人为错误总是存在的,你可能会遗漏一些东西……当这种情况发生时,是时候添加另一个测试然后修复代码了。

于 2008-09-25T20:28:24.007 回答
9

Kent Beck 的建议是编写测试,直到恐惧变成无聊。也就是说,直到你不再害怕任何东西会破裂,假设你从适当程度的恐惧开始。

于 2008-11-16T23:18:55.817 回答
3

在某种程度上,这是一种直觉

“我有信心测试能解决我现在能想到的所有问题吗?”

在另一个层面上,您已经有一组必须满足的用户或系统要求,因此您可以停在那里。

虽然我确实使用代码覆盖率来告诉我是否没有遵循我的 TDD 流程并找到可以删除的代码,但我不会将代码覆盖率视为知道何时停止的有用方法。您的代码覆盖率可能是 100%,但如果您忘记包含需求,那么您并没有真正完成,是吗。

也许对 TDD 的误解是您必须预先了解所有内容才能进行测试。这是错误的,因为 TDD 过程产生的测试就像一个面包屑轨迹。你知道过去测试了什么,并且可以在一定程度上指导你,但它不会告诉你下一步该做什么。

我认为 TDD 可以被认为是一个进化过程。也就是说,你从你的初始设计开始,它是一组测试。随着您的代码在生产中受到重创,您会添加更多测试以及使这些测试通过的代码。每次你在这里添加一个测试,在那里添加一个测试,你也是在做 TDD,而且成本并不高。当您编写第一组测试时,您不知道存在这些案例,但是您现在获得了知识,并且可以通过按一下按钮来检查这些问题。这就是 TDD 的巨大力量,也是我如此提倡它的原因之一。

于 2008-09-25T20:45:30.910 回答
2

好吧,当您想不出更多无法按预期工作的失败案例时。

TDD 的一部分是保留您想要实现的事物的列表,以及当前实现的问题......所以当这个列表用完时,你基本上完成了......

请记住,当您发现实施的错误或新问题时,您可以随时返回并添加测试。

于 2008-09-25T20:25:55.497 回答
2

那个常识,没有完美的答案。TDD 的目标是消除恐惧,如果您有信心对它进行了足够好的测试,请继续...

只是不要忘记,如果您以后发现错误,请先编写测试以重现错误,然后更正它,这样您就可以防止将来的更改再次破坏它!

有些人在没有 X% 的覆盖率时会抱怨……有些测试是无用的,100% 的覆盖率并不意味着你测试了所有可能使你的代码崩溃的东西,只是它不会因为你使用的方式而崩溃它!

于 2008-09-25T20:27:13.653 回答
2

测试是一种精确描述你想要的东西的方式。添加测试可扩展您想要的范围,或添加您想要的详细信息

如果你想不出更多你想要的东西,或者对你想要的东西进行任何改进,那就继续做其他事情。您可以稍后再回来。

于 2008-10-05T04:00:07.000 回答
2

TDD 中的测试是关于覆盖规范的,实际上它们可以替代规范。在 TDD 中,测试并不是要覆盖代码。他们确保代码涵盖规范,因为如果代码不涵盖规范,则测试将失败。您拥有的任何额外代码都无关紧要。

因此,当测试看起来描述了您或利益相关者的所有期望时,您就有了足够的测试。

于 2008-10-05T04:01:16.280 回答
1

也许我错过了 Agile/XP 世界的某个地方,但我对这个过程的理解是开发人员和客户将测试指定为 Feature 的一部分。这允许测试用例替代更正式的需求文档,帮助识别功能的用例等。因此,当所有这些测试通过时,您就完成了测试和编码......加上您认为的任何边缘案例一路上的

于 2008-09-25T21:04:08.900 回答
1

Alberto Savoia如果你所有的测试都通过了,那么你的测试很可能不够好”。我认为这是思考测试的好方法:询问你是否在做边缘情况,传递一些意想不到的参数等等。提高测试质量的一个好方法是与一对 - 特别是测试人员一起工作 - 并获得有关更多测试用例的帮助。与测试人员结对很好,因为他们有不同的观点。

当然,您可以使用一些工具进行突变测试并从测试中获得更多信心。我使用过Jester,它改进了我的测试和我编写它们的方式。考虑使用类似的东西。

亲切的问候

于 2008-09-25T21:25:37.037 回答
1

从理论上讲,您应该涵盖所有可能的输入组合并测试输出是否正确,但有时它只是不值得。

于 2008-09-25T21:44:10.940 回答
1

许多其他评论都一针见血。鉴于您的测试覆盖率,您对您编写的代码有信心吗?随着代码的发展,您的测试是否仍能充分覆盖它?您的测试是否捕获了被测组件的预期行为和功能?

必须有一个快乐的媒介。随着您添加越来越多的测试用例,您的测试可能会变得脆弱,因为边缘用例会不断变化。遵循许多早期的建议,提前获得您能想到的所有内容,然后随着软件的发展添加新的测试,这会非常有帮助。这种有机增长可以帮助您的测试增长,而无需预先付出所有努力。

我不会撒谎,但是当我回去编写额外的测试时,我经常会变得懒惰。我可能会错过包含 0 代码的属性或我不关心的默认构造函数。有时,不完全了解流程可以为您节省时间 n 次重要的领域(100% 代码覆盖率神话)。

您必须记住,最终目标是推出一流的产品,而不是在测试中杀死自己。如果你有那种感觉就像你错过了一些东西,那么你很有可能有,你需要添加更多的测试。

祝你好运,编码愉快。

于 2008-10-05T03:50:59.483 回答
0

您总是可以使用像 EMMA ( http://emma.sourceforge.net/ ) 或其 Eclipse 插件 EclEmma ( http://www.eclemma.org/ ) 之类的测试覆盖工具。一些开发人员认为 100% 的测试覆盖率是一个有价值的目标;其他人不同意。

于 2008-09-25T20:26:08.367 回答
0

试着在合理的范围内想出所有可能导致失败的方法。Null 值、超出范围的值等。一旦你不能轻易提出任何事情,就继续做其他事情。

如果你在路上发现了一个新的错误或想出了一个方法,添加测试。

这与代码覆盖率无关。这是一个危险的指标,因为代码在“测试良好”之前就已经“覆盖”了很久。

于 2008-09-25T20:40:26.943 回答