使用测试驱动开发实现后更改类答案

【问题标题】：Changing a class after implementing with Test Driven Development使用测试驱动开发实现后更改类
【发布时间】：2014-12-15 21:21:45
【问题描述】：

我使用 TDD 方法为我的应用程序编写的第一个类是配置文件处理程序。我为我认为需要的所有方法编写了单元测试，并将实际逻辑实现到类中。在完成最后一个方法的实现并确保所有单元测试都通过后，我开始着手处理需要使用配置文件处理程序的类。

然而，在开始开发另一个类时，我意识到我的配置文件处理程序实现的一部分还不够，所以我不得不重新编写一些方法——这破坏了我对配置的大量单元测试文件处理程序。

在这种情况下，我应该重新编写这些测试吗？还是我应该保留原来的方法并编写额外的方法？

【问题讨论】：

还有其他人会使用您最初编写的方法吗？如果没有，保留死代码就没有意义了。
我觉得有益的是为相关类定义一个接口。而我的单元测试只会测试接口的公共方法和属性。然后，如果我需要重构和更改我的内部实现，我的单元测试不应该中断。如果我更改接口，我的单元测试将只需要修改。

【解决方案1】：

如果不需要，不要保留原始方法。这就是重构的本质。根据需要更正单元测试并丢弃不再相关的测试。

【讨论】：

事实上，我认为编写你认为需要的方法是错误的。这是TDD的价值之一。您应该只编写您需要通过的单元测试，并且您应该只编写使这些测试通过所需的代码。我会首先为将要使用配置类的代码编写测试。那会告诉你配置类需要哪些测试。
好的，所以错误是从底部开始的？我应该从更高层次开始，并创建我当时需要的测试和课程？
这不是一个错误。一个人应该从你认为的第一个测试用例开始，而不是高或低，而是简单的。在什么抽象级别上并不重要。如果您还没有准备好编写配置类，那么就从简单的开始吧。
@Bruce：你怎么知道第一个测试应该是什么？我只能从两个方面考虑编写软件；从底部开始向上工作，或者考虑第一个用例将是什么并从那里开始......这更像是从顶部开始并一直工作到底部。
你的单元测试出了什么问题？您是否修改了类的公共签名或更改类的内部实现是否破坏了您的单元测试？