testing - 在执行 TDD 时发现其他对象

Question

我正在尝试练习 TDD。

我的理解是TDD应该这样走

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

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

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

1. 暂时搁置现有的测试列表，为新发现的类创建一个新的(在实现新类的过程中会出现同样的问题)
2. 采用基于交互的测试方法并模拟新类，继续您正在处理的类的测试用例，稍后回来创建模拟类的正确实现。
3. 这种情况不应该出现。我可能没有充分考虑我的初始设计。 (但这不会破坏 TDD 的目的之一吗？!)。

我很想知道其他人是如何处理这些情况的。

Answer 1

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

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

并且通常(尤其是在架构复杂的应用程序中，如 n 层应用程序)一定数量的前期设计。没有什么是一成不变的，但足以给单位一个去处。当然，架构可能会以敏捷的方法发展，但如果架构有多个层次，则需要有一个总体的概念。

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