在进行TDD时，如何分辨"对于该类/功能来说已经足够了测试"？

IE。我们什么时候可以说我们已经完成了对所有边缘情况的测试？

解决方案

好吧，当我们再也无法想到无法正常工作的失败案例时。

TDD的一部分是保留我们要实现的事情的列表，以及当前实现的问题...因此，当该列表用完时，我们实际上已经完成了...。

请记住，当发现实施中的错误或者新问题时，我们总是可以返回并添加测试。

我们始终可以使用诸如EMMA(http://emma.sourceforge.net/)或者其Eclipse插件EclEmma(http://www.eclemma.org/)之类的测试覆盖率工具。一些开发人员认为100％的测试覆盖率是一个值得追求的目标。其他人不同意。

那种常识，没有完美的答案。 TDD的目标是消除恐惧，如果我们确信自己已经对它进行了充分的测试，请继续...

只是不要忘记，如果以后发现错误，请首先编写一个测试以重现该错误，然后更正它，这样我们就可以防止以后的更改再次破坏它！

有些人抱怨当他们没有X％的覆盖率时...。有些测试是无用的，而100％的覆盖率并不意味着我们在测试所有可能导致代码破坏的事物，仅是事实不会破坏使用方式它！

使用测试驱动开发，我们需要先编写测试，然后再编写要测试的代码。一旦我们编写了代码并通过了测试，就可以编写另一个测试了。如果我们正确遵循TDD，则只要代码满足了所有要求，就可以编写足够的测试。

对于边缘情况，让我们举一个例子，例如验证方法中的参数。在将参数添加到代码中之前，我们需要创建测试以验证代码可以正确处理每种情况。然后，我们可以添加参数和关联的逻辑，并确保测试通过。如果我们考虑更多的边缘情况，那么可以添加更多的测试。

通过一次迈出一步，当我们编写完代码后，我们将不必担心边缘情况，因为我们已经为所有情况编写了测试。当然，总会有人为错误，我们可能会漏掉一些东西……当发生这种情况时，就该添加另一个测试，然后修复代码了。

只要设法在可能导致某些故障的原因内想出一切办法即可。空值，超出范围的值等。一旦我们无法轻松提出任何内容，就继续进行其他操作。

如果在旅途中我们发现了新的错误或者提出了解决方法，请添加测试。

这与代码覆盖率无关。这是一个危险的指标，因为代码在"经过良好测试"之前就已经"被发现"了。

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

"Am I confident that the tests will catch all the problems I can think of
  now?"

在另一个层次上，我们已经具有一组必须满足的用户或者系统要求，因此我们可以在此停止。

虽然我确实使用代码覆盖率来告诉我是否不遵循TDD流程并查找可以删除的代码，但我不会将代码覆盖率视为知道何时停止的有用方法。代码覆盖率可能是100％，但是，如果我们忘了包含一个要求，那么我们还没有真正完成。

关于TDD的一个误解可能是我们必须先了解所有内容才能进行测试。这是被误导的，因为TDD流程产生的测试就像一条面包屑痕迹。我们知道过去测试过的内容，可以在某种程度上指导我们，但是不会告诉我们下一步该怎么做。

我认为TDD可以看作是一个进化过程。也就是说，我们从初始设计开始，并进行了一系列测试。随着代码在生产中遭受重创，我们将添加更多测试，并使这些测试通过的代码。每次我们在此处添加测试，然后在此处进行测试时，我们也在进行TDD，而且花费不那么多。我们在编写第一组测试时并不知道这些情况是否存在，但是现在我们已经掌握了知识，并且可以通过按一下按钮来检查这些问题。这是TDD的强大力量，也是我之所以如此主张的原因之一。

也许我错过了敏捷/ XP世界中的某个地方，但是我对流程的理解是，开发人员和客户将测试指定为功能的一部分。这允许测试用例代替更正式的需求文档，帮助确定功能的用例，等等。因此，当所有这些测试通过时，我们就完成了测试和编码……再加上我们认为的其他边缘用例。一路走来

阿尔贝托·萨沃亚(Alberto Savoia)说："如果我们所有的测试都通过了，那么测试很可能还不够好。"我认为这是考虑测试的好方法：询问我们是否在进行边缘测试，传递一些意外参数等。提高测试质量的一种好方法是与一对测试人员一起工作，并获得有关更多测试用例的帮助。与测试人员配对是一件好事，因为他们有不同的观点。

当然，我们可以使用某些工具进行突变测试，并从测试中获得更大的信心。我使用了Jester，它可以改善我的测试以及我编写它们的方式。考虑使用类似的东西。

亲切的问候

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

其他许多评论都触动了头脑。我们对测试覆盖范围内编写的代码是否有信心？随着代码的发展，测试是否仍能覆盖其中？测试是否捕获了被测组件的预期行为和功能？

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

我不会说谎，但是回去编写其他测试时我经常会变得懒惰。我可能会错过包含0代码的属性或者我不在乎的默认​​构造函数。有时，不完全了解该过程可以为我们节省n个比关键要少的时间(100％代码覆盖率的神话)。

我们必须记住，最终目标是将一流的产品推向市场，而不是扼杀自己的测试。如果我们感觉自己好像丢失了某些东西，那么我们就有机会并且需要添加更多测试。

祝我们好运，编码愉快。

测试是一种精确描述我们想要的东西的方法。添加测试可扩展所需范围，或者添加所需详细信息。

如果我们想不出想要的任何东西，或者对想要的东西没有任何细化，请继续进行其他操作。我们以后总是可以回来的。

TDD中的测试是关于覆盖规范的，实际上，它们可以替代规范。在TDD中，测试与覆盖代码无关。他们确保代码覆盖规范，因为如果代码不覆盖规范，则测试将失败。我们拥有的任何多余代码都没有关系。

因此，当测试看起来像描述我们或者利益相关者的所有期望时，我们就有足够的测试。

肯特·贝克(Kent Beck)的建议是编写测试，直到恐惧变成无聊为止。也就是说，假设我们从适当的恐惧水平开始，直到我们不再害怕任何事情都会破裂。