在进行TDD时,如何判断“对于此类/功能的测试已经足够了”?
即你什么时候可以告诉你完成了所有边缘情况的测试?
使用测试驱动开发,您将在编写测试代码之前编写测试。编写完代码并且测试通过后,就该编写另一个测试了。如果你正确地遵循了 TDD,那么一旦你的代码完成了所有需要的测试,你就已经编写了足够多的测试。
至于边缘情况,我们举一个例子,比如验证方法中的参数。在将参数添加到代码之前,您需要创建测试来验证代码将正确处理每种情况。然后您可以添加参数和关联的逻辑,并确保测试通过。如果您想出更多边缘情况,则可以添加更多测试。
通过一步一步来,您在编写完代码后就不必担心边缘情况,因为您已经为所有情况编写了测试。当然,人为错误总是存在的,你可能会遗漏一些东西……当这种情况发生时,是时候添加另一个测试然后修复代码了。
Kent Beck 的建议是编写测试,直到恐惧变成无聊。也就是说,直到你不再害怕任何东西会破裂,假设你从适当程度的恐惧开始。
在某种程度上,这是一种直觉
“我有信心测试能解决我现在能想到的所有问题吗?”
在另一个层面上,您已经有一组必须满足的用户或系统要求,因此您可以停在那里。
虽然我确实使用代码覆盖率来告诉我是否没有遵循我的 TDD 流程并找到可以删除的代码,但我不会将代码覆盖率视为知道何时停止的有用方法。您的代码覆盖率可能是 100%,但如果您忘记包含需求,那么您并没有真正完成,是吗。
也许对 TDD 的误解是您必须预先了解所有内容才能进行测试。这是错误的,因为 TDD 过程产生的测试就像一个面包屑轨迹。你知道过去测试了什么,并且可以在一定程度上指导你,但它不会告诉你下一步该做什么。
我认为 TDD 可以被认为是一个进化过程。也就是说,你从你的初始设计开始,它是一组测试。随着您的代码在生产中受到重创,您会添加更多测试以及使这些测试通过的代码。每次你在这里添加一个测试,在那里添加一个测试,你也是在做 TDD,而且成本并不高。当您编写第一组测试时,您不知道存在这些案例,但是您现在获得了知识,并且可以通过按一下按钮来检查这些问题。这就是 TDD 的巨大力量,也是我如此提倡它的原因之一。
好吧,当您想不出更多无法按预期工作的失败案例时。
TDD 的一部分是保留您想要实现的事物的列表,以及当前实现的问题......所以当这个列表用完时,你基本上完成了......
请记住,当您发现实施的错误或新问题时,您可以随时返回并添加测试。
那个常识,没有完美的答案。TDD 的目标是消除恐惧,如果您有信心对它进行了足够好的测试,请继续...
只是不要忘记,如果您以后发现错误,请先编写测试以重现错误,然后更正它,这样您就可以防止将来的更改再次破坏它!
有些人在没有 X% 的覆盖率时会抱怨……有些测试是无用的,100% 的覆盖率并不意味着你测试了所有可能使你的代码崩溃的东西,只是它不会因为你使用的方式而崩溃它!
测试是一种精确描述你想要的东西的方式。添加测试可扩展您想要的范围,或添加您想要的详细信息。
如果你想不出更多你想要的东西,或者对你想要的东西进行任何改进,那就继续做其他事情。您可以稍后再回来。
TDD 中的测试是关于覆盖规范的,实际上它们可以替代规范。在 TDD 中,测试并不是要覆盖代码。他们确保代码涵盖规范,因为如果代码不涵盖规范,则测试将失败。您拥有的任何额外代码都无关紧要。
因此,当测试看起来描述了您或利益相关者的所有期望时,您就有了足够的测试。
也许我错过了 Agile/XP 世界的某个地方,但我对这个过程的理解是开发人员和客户将测试指定为 Feature 的一部分。这允许测试用例替代更正式的需求文档,帮助识别功能的用例等。因此,当所有这些测试通过时,您就完成了测试和编码......加上您认为的任何边缘案例一路上的
从理论上讲,您应该涵盖所有可能的输入组合并测试输出是否正确,但有时它只是不值得。
许多其他评论都一针见血。鉴于您的测试覆盖率,您对您编写的代码有信心吗?随着代码的发展,您的测试是否仍能充分覆盖它?您的测试是否捕获了被测组件的预期行为和功能?
必须有一个快乐的媒介。随着您添加越来越多的测试用例,您的测试可能会变得脆弱,因为边缘用例会不断变化。遵循许多早期的建议,提前获得您能想到的所有内容,然后随着软件的发展添加新的测试,这会非常有帮助。这种有机增长可以帮助您的测试增长,而无需预先付出所有努力。
我不会撒谎,但是当我回去编写额外的测试时,我经常会变得懒惰。我可能会错过包含 0 代码的属性或我不关心的默认构造函数。有时,不完全了解流程可以为您节省时间 n 次重要的领域(100% 代码覆盖率神话)。
您必须记住,最终目标是推出一流的产品,而不是在测试中杀死自己。如果你有那种感觉就像你错过了一些东西,那么你很有可能有,你需要添加更多的测试。
祝你好运,编码愉快。
您总是可以使用像 EMMA ( http://emma.sourceforge.net/ ) 或其 Eclipse 插件 EclEmma ( http://www.eclemma.org/ ) 之类的测试覆盖工具。一些开发人员认为 100% 的测试覆盖率是一个有价值的目标;其他人不同意。
试着在合理的范围内想出所有可能导致失败的方法。Null 值、超出范围的值等。一旦你不能轻易提出任何事情,就继续做其他事情。
如果你在路上发现了一个新的错误或想出了一个方法,添加测试。
这与代码覆盖率无关。这是一个危险的指标,因为代码在“测试良好”之前就已经“覆盖”了很久。