我发现重构架构在设计仍在制定的早期阶段是更常见的。接口改变，新类加入&删除，甚至一个函数的行为可能会有轻微的变化(我认为我需要它做到这一点，但它实际上需要这样做)，等等…但如果每个测试用例是紧密耦合到这些不稳定的类，不会你必须不断地重写你的测试用例每次你改变一个设计？
在TDD的什么情况下，是否可以更改和删除测试用例？如何确保改变测试用例不会破坏测试用例？另外，似乎不得不同步一个全面的测试套件与不断变化的代码将是一个痛苦。我知道单元测试套件在维护期间可以帮助非常大，一旦软件构建，稳定和正常运行，但是在游戏的后期，TDD也应该在早期帮助。
最后，一本关于TDD和/或重构的好书能解决这些问题吗？如果是这样，你会推荐什么？
Plus it seems that having to
synchronize a comprehensive test suite
with constantly changing code would be
a pain. I understand that the unit
test suite could help tremendously
during maintenance,once the software
is built,stable,and functioning,but
that’s late in the game wheras TDD is
supposed to help early on as well.
我确实同意，在发生主要架构变化时，在这些早期变化时可以感觉到具有单元测试套件的开销，但是我认为，单元测试的好处远远超过这个缺点。我认为问题常常是一个精神问题 – 我们倾向于认为我们的单元测试是代码库的第二类公民，我们不得不混淆他们。但是随着时间的推移，我已经依赖于他们并欣赏它们的有用性，我已经认为它们与代码库的任何其他部分一样重要，不逊于维护和工作。
主要的架构“变化”是否真的只是重构？如果你只是重构，但是显着，测试开始失败，这可能会告诉你，你不经意地改变了某处的功能。这是什么单位测试应该帮助你抓住。如果你正在对功能和架构同时进行彻底的更改，你可能想考虑放慢和进入红/绿/重构槽：没有新的(或改变的)功能，无额外的测试，没有更改功能(和中断测试)。
更新(基于评论)：
@Cybis提出了一个有趣的反对我的说法，重构不应该打破测试，因为重构不应该改变行为。他的反对意见是重构确实改变了API，因此测试“break”。
首先，我鼓励任何人访问重构的规范参考：Martin Fowler’s bliki.刚刚我检查了它，一些事情跳出我：
> Is changing an interface
refactoring? Martin指的是
重构为
“行为保持”的变化，这
意味着当接口/ API改变时
然后所有的呼叫者
接口/ API也必须更改。
包括测试，我说。
>这并不意味着行为已经改变。同样，福勒强调他的
重构的定义是
更改是行为
保存。
鉴于此，如果一个或多个测试在重构期间必须改变，我不认为这是“中断”测试。它只是重构的一部分，保留整个代码库的行为。我认为在必须更改的测试和代码库的任何其他部分必须作为重构的一部分进行更改之间没有差别。 (这回到我之前说的考虑测试是代码基础的一流公民。)
此外，我希望测试，即使是修改的测试，一旦重构完成后继续传递。无论那个测试是测试(可能是测试中的断言)在重构完成后仍然是有效的。否则，这是一个红色的标志，行为改变/回归在重构期间不知何故。
也许这个声明听起来像废话，但想想：我们不考虑在生产代码库中移动代码块，期望他们继续在他们的新上下文中工作(新类，新的方法签名，无论什么)。我对测试有同样的感觉：也许一个重构改变了一个测试必须调用的API，或者一个测试必须使用的类，但是最终测试的点不应该因为重构而改变。
(我唯一能想到的例外是测试在重构过程中可能需要改变的低级实现细节，例如用ArrayList或其他东西替换LinkedList，但在这种情况下，可以认为测试是过度测试，太僵硬和脆弱。)
