我听说使用TDD开发的项目更容易进行重构，因为这种实践会产生一组全面的单元测试，如果任何更改破坏了代码，这些测试用例（希望如此）将会失败。然而，我所看到的所有示例都涉及到重构实现 - 比如用更高效的算法进行更改。
但是，在早期设计仍在进行的阶段，重构架构要更加常见。接口会改变，新类会被添加和删除，甚至函数的行为也可能稍微改变（我认为它需要做这个，但实际上它需要做那个），等等... 但是，如果每个测试用例都与这些不稳定的类紧密耦合，难道你不必每次更改设计时都不断重写测试用例吗？
在TDD的哪些情况下修改和删除测试用例是可以的？您如何确保修改测试用例不会破坏它们？此外，似乎需要将全面的测试套件与不断变化的代码进行同步会很麻烦。我理解，一旦软件建立，稳定并运行良好，单元测试套件在维护过程中可以非常有帮助，但这是在游戏晚期，而TDD应该在早期也有所帮助。
最后，好的TDD和/或重构书籍是否会解决这些问题？如果是，您会推荐哪一本？
我确实同意，在进行重大架构更改时，已经有一个单元测试套件会感受到额外负担，但我的观点是，拥有单元测试的好处远远超过这个缺点。我认为问题通常是心理上的——我们倾向于认为我们的单元测试是代码库中次等公民，并且我们不喜欢去处理它们。但随着时间的推移，当我依赖它们并欣赏它们的用处时，我开始认为它们和代码库中的任何其他部分一样重要，也同样值得维护和工作。
主要的架构“变化”是否真的只是重构？如果你只是进行重构，不管有多大改动，测试开始失败了，这可能表明你无意中改变了某个功能。而单元测试就是帮助你发现这些问题的。如果你同时对功能和架构进行全面的更改，你可能需要考虑放慢速度，并进入红/绿/重构的节奏：没有额外的测试就不添加新的（或更改的）功能，而在重构时不改变功能（并破坏测试）。鉴于此，如果在重构过程中需要更改一个或多个测试，我不认为这会“破坏”测试。这只是重构的一部分，是为了保留整个代码库的行为。在重构过程中，我认为测试需要和代码库的任何其他部分一样被重视。（这又回到了我之前所说的将测试视为代码库中的一等公民。）
此外，我希望测试，即使是修改后的测试，在重构完成后仍然能够“继续通过”。无论那个测试在测试什么（可能是测试中的assert(s)），重构完成后应该仍然有效。否则，这表明在重构过程中行为发生了变化或退化，这是一个警示信号。TDD的意思是先写一个失败的测试。这个测试被写出来是为了展示开发者理解用例/故事/场景/流程的目的。
然后你编写代码以满足测试。
如果需求变化或被误解，先编辑或重写测试。
红灯，绿灯，对吧？
Fowler的《重构》是重构的参考书，很奇怪。
Scott Ambler在《Dr. Dobb's》杂志上的系列文章（“敏捷边缘？”）是TDD实践的很好的演示。
例如使用更有效的算法来替换原有算法，这就是性能优化，而不是重构。重构是关于改进现有代码的设计，即更改其形态以更好地满足开发者的需求。 改变代码以影响外部可见行为并不是重构，包括为了提高效率而进行的更改。
TDD 的价值之一在于您的测试可以帮助您在改变产生结果的方式时保持可见行为不变。
if definition of correctness changes
change tests/specs
end
if definition of correctness does not change
# no need to change tests/specs
# though you still can for other reasons if you want/need
end
因此，如果应用程序/系统规格或期望的行为发生变化，改变测试是必要的。在这种情况下仅更改代码而不更改测试显然是错误的方法。你可能认为这很痛苦，但没有测试套件更加痛苦。:) 正如其他人所提到的，拥有那种“敢于”更改代码的自由确实非常有力和解放。:)
肯特·贝克的TDD书。
先测试。遵循S.O.L.I.D面向对象编程原则和使用良好的重构工具是必不可少的，如果不是必需的话。