测试驱动的开发（TDD，Test Driven Development）的核心理念，是要使得重构（refactoring）更为有效，而不是创建更多的测试。
对一个有着长生命周期的项目来讲，在它的第一个版本，通常具有好的、干净的架构。随着版本的不断更新，会引入越来越多旁门左道的变通方法（hacky workaround）、捷径（short cuts）、不一致的接口（inconsistent interfaces）、难以理解的契约（confusing contracts）等，这样项目就会变得越来越难以维护（尤其是我们的那些已经过时的代码）。那么，怎么能够避免这种情况的出现呢？关键就是，项目代码要具备能够自由重构而不引入回归（regression）的能力。测试驱动的开发提供了这种能力。
基于这样的理解，我们应该将单元测试写成是代码重构的工具。什么意思呢？测试用例的首要原则：当重构代码的时候，不应该改变单元测试。
考虑相反的情况，当我们试图去重构项目代码时，修改了一些单元测试依赖的接口。因此我们需要同步地修改单元测试的代码。那么我们怎么才能确定在单元测试中没有产生regression？这样的单元测试，不但不能够帮助进行代码重构，反而成为了一种负担。这也是我们很多已过时的测试存在的问题：当我们改变源代码，需要花费很多的时间去更新测试。
这就是为什么最佳实践之一是“只针对公共接口（public interface）写单元测试”的原因。公共接口通常是要相对更加稳定的（否则会影响到用户）。如果单元测试针对internal接口，重构的时候要么不去改变这些接口，要么就必须同步修改测试代码。