Java 在TDD中，在重构过程中将主类拆分为子类

我试着跟随TDD，我对它有点陌生。我有一个要实现的接口（Java）

所以我开始为接口行为编写测试用例，使它们失败，并通过添加或修改代码来修复它们

然而，当我看到主类的大小在增长时，我将主类划分为不同的类。但是对于一些子类，我意识到最好单独测试它们，并在主类测试用例中模拟它们

但是当我这样做的时候，我不得不再次重写主要的类测试用例（对于移动的代码），导致大量的混乱和重复工作

---

我在实施TDD方法时是否做错了什么？

听起来你做得差不多。然而，有几点需要说明。重新启动以确保我们在同一页上：

要从主类a中提取辅助类B

• 从A中重构B
• 为B编写测试（参考A的测试）
• 删除与B测试重复的A测试
• 如果合适，重写A的其余测试，这些测试依赖于B中现在的功能，以使用B的模拟

一些建议：

• 提取帮助器类后，可以删除除一个（或几个）测试帮助器类功能的主类测试之外的所有测试。因此，您不应该有太多需要重写的主类测试
  例如，如果主类对一个人进行建模，而助手类根据其给定的姓名、姓氏、头衔等构造该人的全名，则主类最初将对该功能进行许多测试：一个给定的姓名与多个姓名、头衔与无头衔等。您将为助手类编写等效的测试，然后删除所有关于全名构造的主要类测试，只有一个除外。您确实需要在主类中留下一个测试，测试它是否知道如何构造某种全名；如果您错误地删除了对helper类的调用或类似的东西，那么该测试将失败

• 如果helper类很简单（特别是，如果它没有需要特殊测试设置或导致测试速度缓慢的严重依赖项），则不必对其进行模拟。这可能会为您节省一些重写主类测试的时间

• 这个过程确实需要对测试和代码进行返工提前思考并在您确信重构会有所帮助时尽快进行重构，从而最大限度地减少返工。我发现，当我认为需要提取类时，我通常是对的；我以后很少需要内联类。因此，积极地提取类通常不会导致额外的工作，而是通过更快地找到正确的对象模型来将其最小化

---

广泛相关：关于#3提前思考的建议。。我听说我们可以使用TDD来帮助实现良好的低层设计。那么，在编写测试用例之前，先思考一下，这不是违反了TDD的这一原则或好处吗？不，这是最大限度地发挥了TDD的好处！我不是建议你考虑一个设计，不管你的测试和重构告诉你什么。我的建议是，在实现每个测试之后，在重构刚编写的代码时，您应该谨慎且深思熟虑，以便在代码开始告诉您这些重构时，尽可能看到有用的更大重构（如提取类）。