TDD - 单元测试推动开发但不是同义反复

Question

我已经开始做一些TDD并且正在享受这个过程，但遇到了一个问题。

我倾向于编写测试，这是一种“一厢情愿”的测试。我的意思是编写测试，断言该单元已经调用了当前不存在的方法，然后对结果做了一些事情 - 这需要相当多的模拟/存根。这让我编写了一些很好的代码（我认为），它在不同的逻辑块之间有很好的干净接口。

然而，我刚看了一些我写的模块的测试，其中很多看起来都是毫无意义的。他们基本上断言代码中写的内容是写在代码中的。一旦我做任何重构，它们就会破裂。

我一直在尝试的玩具问题：我需要编写一个javascript source函数，以便在jQuery autocomplete plugin中使用。

该功能需要：

• 检查数据是否已从服务器中提取（如果没有，则检查 它）
• 使用该数据创建一系列可能的建议
• 根据用户目前输入的内容过滤数组（为了增加一些复杂性，在我的实验中，我一直假设我想在这里实际创建两个数组 - 一个包含从用户开始的所有术语输入和一个包含所有包含用户输入的项减去第一个数组中的项
• 组合数组并将它们传递回回调函数

我认为自己有两种选择。我一直在两条路线上进行比较。

我可以从编写仅测试我的函数的业务逻辑的测试开始（也许只是模拟对从服务器获取东西的ajax函数的调用）。仅测试函数返回它应该执行的操作。这样我最终得到的测试如果我决定重构就不会破坏。但我最终还是得到了一些我可能想要重构的混乱代码。

或者我可以沿着'一厢情愿'的路线走下去 - 编写断言调用（当前）虚构方法的测试，并将逻辑分散到更小的块中。这推动了开发，因为测试要求我编写代码来调用这些方法，然后我为方法本身编写了更多的测试等等。这次我最终得到了更好的代码，但我似乎也最终得到了一堆重复测试

我错过了什么吗？是否有幸福的中间地带？任何经验丰富的TDD可以举例说明他们将从哪些测试开始？

Answer 1

TDD代表测试驱动设计，这意味着您的测试会驱动代码。

正如您已经说过的那样，在做“一厢情愿”时，您最终会得到干净的代码，这些代码易于阅读和维护。当然，在这种情况下，您有更多的测试看起来是“同义反复”，并且您需要更多时间来编写它们，但是每个测试都描述了您对所需行为的关注。您在额外测试上花费的所有额外时间将在系统开始增长后得到回报，但您的代码仍将保持清洁和可维护。