TDD假设接口已经定义；如何应对？

要在编写代码之前编写测试，您需要有一种与代码交互的方法。测试倾向于提前定义接口，以便只编写测试

但是，开发一个好的实现通常需要发明一组好的组件间接口，多次调整和重新设计这些接口。在此期间，您要么继续重写测试代码的好部分，要么允许测试落后于代码

---

有什么最佳实践可以缓解这种情况吗？

这听起来像是整个红绿重构循环。也就是说，TDD在某种程度上是关于接口的重写。这使他们精力充沛，直截了当。一旦你掌握了TDD的诀窍，并且你编写了面向接口的测试，并保持了对象的小型化，你就不会看到有太多的变化，除非你遇到了一些不可预见的事情，并且必须进行调整，这就是敏捷的要点（希望这就是为什么你要进行TDD）

---

不过，这听起来有点像是一次性定义了整个接口。这是错误的。一个测试应该在接口中生成一个函数，这是预期的行为。您的界面将随着测试套件的增长而增长，从而最大限度地减少任何回补。

我同意@Per Fagrell-s“界面将随着时间的推移而增长”

---

备选方案：如果您正在创建具有广泛功能的BusinessClass，那么为不同方面或子功能定义多表接口如何？正如您编写测试时，如果您正在测试的代码已经编写，那么您可以（并且应该）编写它们，就好像接口已经编写一样。这是测试驱动设计的部分，也是最重要的部分。你知道你要从你的测试类中获得什么功能；编写测试，就好像该功能已经存在一样。您现在在测试中使用的名称和参数；作为被测试代码和接口的客户，您自然会想到什么；这些元素在类及其接口的设计中占有突出地位。

单元测试失败不仅仅是检查失败。失败的单元测试编译也可以被视为失败的测试。因此，编写单元测试，因为接口就在那里

---

TDD-测试驱动设计-设计意味着改变接口。

在我对任何编程都没有太多经验之前，我就试图进入测试驱动开发，为此我做了很多努力。我最终认为，测试可以确认代码按预期工作，但它无法检查您是否拥有良好的设计，如果您的设计随着代码的开发而改变（可能会改变），您只需重写一些测试。我想这会鼓励人们关注代码的设计，这是一件好事。在某些情况下，在不进行测试的情况下，先完成界面设计可能是一个好主意。