在应用TDD时,您使用什么启发式方法来选择下一个要编写的测试？

Question

TDD周期的第一部分是选择失败的测试.我想开始一个关于这个选择过程的社区维基.

有时选择开始的测试是显而易见的,从低悬的果实开始.例如,在编写解析器时,一个简单的测试就是不处理输入的测试:

def testEmptyInput():
  result = parser.parse("")
  assertNullResult(result)

有些测试很容易通过,只需要很少的实现代码,如上例所示.

其他测试需要复杂的实现代码板才能通过,而我还是觉得我没有做过"最容易让测试通过".在这一点上,我停止尝试通过这个测试,并选择一个新的测试试图通过,希望它将揭示有问题的实现更容易的实现.

我想探讨这些简单而具有挑战性的测试的一些特性,它们如何影响测试用例的选择和排序.

测试选择如何与自上而下和自下而上策略相关？任何人都可以推荐与TDD相关的解决这些策略的文章吗？

Answer 1

我首先锚定代码中最有价值的行为。

例如，如果它是验证器，我将首先确保它表明有效对象是有价值的。现在我们可以展示代码，训练用户不要做愚蠢的事情等等——即使验证器永远不会进一步实现。之后，我开始添加边缘情况，首先添加最危险的验证错误。

如果我从解析器开始，而不是从空字符串开始，我可能会从我想要解析的典型但简单的东西以及我想从中得到的东西开始。对我来说，单元测试更像是我将如何使用代码的示例。

我还遵循 BDD 命名测试的做法should- 因此对于您的示例，我将shouldReturnNullIfTheInputIsEmpty(). 这有助于我确定代码应该做的下一个最重要的事情。

这也和BDD的“由外而内”有关。以下是我写的几篇博客文章，可能会有所帮助：Pixie Driven Development和Bug Driven Development。Bug 驱动开发帮助我弄清楚我需要的下一个系统级功能应该是什么，然后帮助我找到下一个单元测试。

不管怎样，希望这能给你一个稍微不同的视角——祝你好运！