在进行 TDD 时发现其他对象答案

【问题标题】：Discovering other objects while doing TDD在进行 TDD 时发现其他对象
【发布时间】：2017-02-27 19:18:03
【问题描述】：

我正在尝试练习 TDD。

我的理解是TDD应该是这样的

为我要开发的接口/类写一个测试列表。
从我的测试列表中最简单但未实现的测试开始。
编写测试，还没有实现代码。
编写类的接口，使代码编译。
运行测试导致一项测试失败。
编写使测试通过的实现。
重构我造成的混乱。
转到 2。

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

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

暂时搁置现有的测试列表，然后为新发现的课程创建一个新列表（在实施新课程的课程时会出现同样的问题）
采用基于交互的测试方式并模拟新类，继续处理您正在处理的类的测试用例，稍后再返回以创建模拟类的正确实现。
这种情况不应出现。我可能还没有很好地考虑我的初始设计。 （但这不会违背 TDD 的目的之一吗？！）。

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

【问题讨论】：

标签： testing tdd

【解决方案1】：

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

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

而且通常（尤其是在架构复杂的应用程序中，例如 n 层应用程序）会进行一些前期设计。没有什么是一成不变的，但足以让这些单位有一个去处。当然，架构可能会以敏捷方法演进，但如果架构有多个层次，则需要有一个总体概念。

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

【讨论】：

但是新类应该自己进行测试，不是吗？如果设计让您喜欢创建多个“支持”类，那么您开始使用的单元测试正在变成集成测试。

【解决方案2】：

我遇到的问题是，当我在某个时间点到达第 6 点和第 7 点随着时间的推移，我总是来到结论是实施我刚刚写的应该委托给另一个班级。

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

但它困扰着你。那么该怎么办？认识到委派给另一个类是一种重构；这是在第 6 步之后，在第 7 步中之后要做的事情。一旦你是绿色的，重构一个更好的设计。您已经完成了新课程的测试；他们只是有线呼叫原始课程。这完全没问题。在提取类和委派之后，如果您更愿意让测试直接调用提取的类：去吧。无害。如果提取的类开始被其他调用者使用，我会推荐它，也许当您开始从其他类调用它时是这样做的好时机（但如果它现在困扰您，请立即执行）。

【讨论】：

【解决方案3】：

当我遇到这种情况时，我会遵循您的解决方案 #1。继续递归，尽可能多地创建你认为合适的类，直到你拥有一组你满意的实现。有了经验，你会发现你的设计反映了你的经验，这样的事情就不会发生那么多了。

【讨论】：

这几乎就是我现在正在做的事情，但我不喜欢这样的事实，它会分散你对你正在测试的课程的注意力。过了一会儿，你回到那个班级，试着找出你离开的地方。
正如 Yishai 所说，你不应该考虑测试类。您正在测试问题解决方案的实现，如果实现恰好跨越多个类，那很好。

【解决方案4】：

您应该创建一个模拟类。具有可预测结果的单一界面。这样你就可以测试原版了。

稍后，您可以对新类重复此过程。

【讨论】：

实际上这是我认为我应该做的，但是在外面，关于“基于状态”与“基于交互的测试”的圣战正在进行。我不喜欢这个解决方案将您的测试与您使用的接口的特定声明联系起来的事实。在基于状态的测试中，我可以更改支持类的接口声明（很可能），而无需更改我的测试用例。使用基于交互的测试，我也必须更改测试用例。