在 TDD 中，在重构期间将 main class 拆分为 sub classes
In TDD, splitting main class into sub classes during refactoring
我正在尝试遵循 TDD，但对它有点陌生。我有一个接口（Java）要实现。
所以我开始为接口行为编写测试用例，使它们失败并通过添加或修改代码来修复它们。
但是，正如我看到主 class 的大小越来越大，我将把主 class 拆分成单独的 class。但是对于一些子 classes，我意识到最好单独测试它们并在主要 class 测试用例中模拟它们。
但是当我这样做时，我不得不再次重写主要的 class 测试用例（对于移动的代码），导致大量的变动和重复工作。
我在实施 TDD 方法时做错了什么吗？
听起来你做得对。但是，有几点需要说明。重申以确保我们在同一页面上：
从主classA中提取一个辅助classB，
- 从 A 重构 B
- 为 B 编写测试（借鉴 A 的测试）
- 删除与 B 的测试重复的 A 测试
- 如果合适，重写 A 的剩余测试或依赖于 B 中现在功能的测试，以使用 B 的模拟
一些建议：
提取助手 class 后，您可以删除主要 class 的测试中的一个（或几个）测试] 测试助手 class 功能 。所以你不应该有很多需要重写的主要 class 测试。
例如，如果主要 class 为一个人建模，而助手 class 根据他们的名字、姓氏、头衔等构建该人的全名，则主要 class 最初对该功能有很多测试：一个给定名称与多个，标题与无标题等。您将为助手 class 编写等效测试，然后删除除一个以外的所有测试关于全名结构的主要 class 测试。您确实需要在主 class 中留下一个测试，测试它是否知道如何构造某种全名；如果您错误地删除了对助手的调用 class 或类似的东西，该测试将失败。
如果助手 class 很简单（特别是，如果它没有需要特殊测试设置或导致速度慢的严重依赖项），则不需要不必模拟它。 这可能会为您节省一些 main-class 测试的重写。
此过程确实需要返工测试和代码。 通过提前思考并在确信重构会有所帮助后立即进行重构，从而最大限度地减少返工。我发现当我认为我需要提取一个 class 时，我'我通常是对的；我以后很少需要内联 class 。因此，积极地提取 classes 通常不会导致额外的工作，而是通过更快地找到正确的 object 模型来最小化它。
我正在尝试遵循 TDD，但对它有点陌生。我有一个接口（Java）要实现。
所以我开始为接口行为编写测试用例，使它们失败并通过添加或修改代码来修复它们。
但是，正如我看到主 class 的大小越来越大，我将把主 class 拆分成单独的 class。但是对于一些子 classes，我意识到最好单独测试它们并在主要 class 测试用例中模拟它们。
但是当我这样做时，我不得不再次重写主要的 class 测试用例（对于移动的代码），导致大量的变动和重复工作。
我在实施 TDD 方法时做错了什么吗？
听起来你做得对。但是，有几点需要说明。重申以确保我们在同一页面上：
从主classA中提取一个辅助classB，
- 从 A 重构 B
- 为 B 编写测试（借鉴 A 的测试）
- 删除与 B 的测试重复的 A 测试
- 如果合适，重写 A 的剩余测试或依赖于 B 中现在功能的测试，以使用 B 的模拟
一些建议：
提取助手 class 后，您可以删除主要 class 的测试中的一个（或几个）测试] 测试助手 class 功能 。所以你不应该有很多需要重写的主要 class 测试。
例如，如果主要 class 为一个人建模，而助手 class 根据他们的名字、姓氏、头衔等构建该人的全名，则主要 class 最初对该功能有很多测试：一个给定名称与多个，标题与无标题等。您将为助手 class 编写等效测试，然后删除除一个以外的所有测试关于全名结构的主要 class 测试。您确实需要在主 class 中留下一个测试，测试它是否知道如何构造某种全名；如果您错误地删除了对助手的调用 class 或类似的东西，该测试将失败。
如果助手 class 很简单（特别是，如果它没有需要特殊测试设置或导致速度慢的严重依赖项），则不需要不必模拟它。 这可能会为您节省一些 main-class 测试的重写。
此过程确实需要返工测试和代码。 通过提前思考并在确信重构会有所帮助后立即进行重构，从而最大限度地减少返工。我发现当我认为我需要提取一个 class 时，我'我通常是对的；我以后很少需要内联 class 。因此，积极地提取 classes 通常不会导致额外的工作，而是通过更快地找到正确的 object 模型来最小化它。