tdd - 在应用 TDD 时，您使用什么启发式方法来选择接下来要编写的测试？

Question

TDD 周期的第一部分是选择要失败的测试。我想创建一个关于这个选择过程的社区维基。

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

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

一些测试很容易通过，只需要很少的实现代码，如上面的例子。

其他测试需要复杂的实现代码块才能通过，我觉得我还没有完成“让测试通过的最简单的事情”。正是在这一点上，我停止尝试通过这个测试，并选择一个新的测试来尝试通过，希望它会为有问题的实现揭示一个更简单的实现。

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

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

Answer 1

我首先锚定代码中最有值(value)的行为。

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

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

我也遵循 BDD 命名测试的实践 should - 所以对于你的例子，我有 shouldReturnNullIfTheInputIsEmpty() .这有助于我确定代码应该做的下一个最重要的事情。

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

无论如何，希望这能给你一个稍微不同的观点——祝你好运!