在进行TDD时发现其他对象

Question

我正在尝试练习TDD。

我的理解是TDD应该像这样

1. 为我要开发的接口/类写一个测试列表。
2. 从我的测试列表中最简单的未实现的测试开始。
3. 编写测试，还没有实现代码。
4. 编写类的接口以使代码编译。
5. 运行测试，导致一次测试失败。
6. 编写实施测试通过。
7. 重构我所造成的混乱。
8. 转到2。

我遇到的问题是在编写实现或进行重构时。我经常得出的结论是，我刚写的实现应该委托给另一个类。

此时真正的TDD应该怎么做？

1. 暂时保留现有的测试列表一段时间，并为新发现的类创建一个新的测试列表（在实施新的课程时，同样的问题可以表现出来）
2. 转到基于交互的测试方法并模拟新类，继续使用您正在处理的类的测试用例，稍后再回来创建模拟类的正确实现。
3. 这种情况不应该出现。我可能还没有充分考虑我的初始设计。 （但这不会破坏TDD的目的之一吗？！）。

我很想知道其他人如何应对这些情况。

Answer 1

不要在测试和类之间寻找一对一的关系。如果您决定引入一个新类，那么让它成为原始测试支持的重构，并在您想要添加功能（或测试您需要的事件）时在适当的位置添加测试（具体取决于具体情况）覆盖你尚未测试的。）

我想补充一点，TDD的主要成功是进入红绿重构的节奏。当你感受到节奏的好处时，你已经开始“得到”它。这并不是说你会发现它在所有情况下都是值得的，但在你感受到这种节奏之前，你还没有达到它的拥护者所喜欢的那样。

通常（特别是在架构复杂的应用程序中，如n层应用程序）有一些预先设计。什么都没有用石头勾勒出来，但足以让这些单位成为一个可以去的地方。当然，体系结构可能会以敏捷方法发展，但如果体系结构有多个层，则需要对景观进行总体思考。

编辑:(回应评论）。新课程是否应该自行测试？不必要。这取决于班级是否发展了自己的重要性。当您进行单元测试时，您正在测试一项功能。它不是一个集成测试，因为涉及两个类。当两个单元开始交互时，它就变成了集成测试。我通常想到的边界是，如果我必须在类组A中设置重要状态以与类组B交互，特别是如果类组A调用类组B和什么我对测试B是如何对A作出反应感兴趣，然后我正在研究集成测试。

Answer 2

  

我遇到的问题是，当我   到达第6点和第6点7，在某些时候   及时我总是来到   结论是我的实施   刚写的应该委托给   另一堂课。

使用不同的类来实现您的设计会更好 - 这就是设计，这就是TDD的重点。所以这是件好事，它不应该打扰你。

但它困扰着你。那么该怎么办？认识到委托给另一个班级是重构;这是在步骤6之后，在步骤7中要做的事情。一旦你变绿了，重构一个更好的设计。你已经完成了新课程的测试;他们只是打电话给原来的班级。那很好。在提取类和委托之后，如果你更愿意让测试直接调用提取的类：去吧。无害。如果提取的类开始被其他调用者使用，我会推荐它，也许当你开始从其他类调用它时是一个很好的时间（但如果它现在让你烦恼，现在就去做）。

Answer 3

当我遇到这种情况时，我会按照您的解决方案＃1。继续递归，根据您的需要制作尽可能多的课程，直到您拥有一系列令您满意的实施。根据经验，您会发现您的设计反映了您的体验，而且这种事情不会发生太多。

Answer 4

您应该创建一个模拟类。具有可预测的报告的单一界面。所以你可以测试一下。

稍后，您可以使用新班级重复此过程。