在进行TDD时，如何判断“对于此类/功能的测试已经足够了”？
即你什么时候可以告诉你完成了所有边缘情况的测试？
alex
问问题
1274 次
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
从理论上讲，您应该涵盖所有可能的输入组合并测试输出是否正确，但有时它只是不值得。
于 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 回答