unit-testing - 功能复杂的TDD如何应用？

Question

Bob 大叔关于测试驱动开发的三个规则陈述如下:

1. 除非是为了让失败的单元测试通过，否则您不得编写任何生产代码。

2. 您不得编写足以导致失败的单元测试；编译失败就是失败。

3. 除了足以通过一个失败的单元测试之外，您不得编写任何更多的生产代码。

在现实世界中，例如，我有一个任务要完成一个需要一些复杂算法(例如一些高级数学知识)的方法，如果我应用上面的 3 个规则，它将是这样的:

• 开始编写测试用例 => 运行并查看它是否失败

• 编写足以使测试通过的代码行

• 重构代码

• 然后重复这个循环。

我的问题是:在这种情况下，这种方法是不是很不切实际并且会分散注意力？

我们为什么不编写第一个测试用例，然后专注于寻找解决方案然后实现它，我的意思是着眼于全局，而不是编写足够的代码来通过第一个测试用例？

Answer 1

我认为另一个答案非常好，但除此之外:如果一个方法需要您实现多个算法 - 您确定这样的方法符合< em>单一职责原则？听起来这一种方法做的事情太多了。

因此，当您退后一步看到使用了 3 种算法时 - 这已经告诉我们每种 算法可能应该进入其自己的方法。而且我们的“初始”方法只会调用这些其他方法来完成一些计算。

朝其他方向发展 - 没有法律阻止您适应 TDD 以满足您的需求。这导致了一种我称之为“自下而上的 TDD”的做法。

它是这样的:不是首先为我的一个巨大的方法编写测试 - 我实际上考虑了在那个巨大的方法中我将需要的不同部分。所以我只写下第一部分的测试；然后实现。我对所有部分都这样做。随着时间的推移，这些部分得到了增强，也许我会在途中将较小的部分合并成更大的部分(这很可能意味着将多个测试也合并到一个更大的测试中)。

这种技术可能意味着您可能最终为您的庞大方法得到一个单一的测试用例——但您实际上使用 TDD 来测试小部分，同时构建“大解决方案”。

换句话说:我不是为那个方法的 public 契约编写一个大的功能测试，而是从为我知道我需要的小辅助方法编写测试开始。最后，这些助手将是私有(private) 方法——直接测试它们没有意义。但是您可以保留在大型公共(public)方法的上下文中有意义的早期测试的那些部分。

长话短说:所有这些技术都是为了指导您找到自己的路。如果您有足够的经验来即时设计，那么以这种方式使用 TDD 是可能的(而且实际上很有趣)!