测试、测试、再测试

为了重构代码，你需要一套可靠的测试，这是没有办法的办法。重构代码可以减少引入错误的机会，但改变代码的设计却会带来大量引入新错误的机会。

重构过程中会出现意想不到的副作用，在类紧密耦合的情况下，你很可能会发现对一个函数的微小改动会导致一个完全独立的类产生负面的副作用。

好的重构效果需要好的测试。这是没有办法的事。

除此以外，从政治角度来看，一些公司在经历了多次糟糕的重构工作后，可能会变得不愿意重构代码；确保有良好的测试，可以让公司确保重构工作不会破坏功能。

在本书的下一章（也是最后一章），我将讨论行为测试（用于 BDD）。单元测试是开发人员测试给定代码单元的最佳机制；单元测试补充了代码结构，证明了方法的作用，并测试了代码单元之间的交互；从这个意义上说，单元测试是开发人员在重构工作中可以使用的最佳测试形式。而行为测试则是为了测试代码的行为，因此在证明应用程序能够成功完成特定行为时非常有用。

每个经验丰富的开发人员都会回忆起痛苦的调试任务，有时甚至是彻夜不眠。让我们想想大多数开发人员的日常工作方式。他们并不是时时刻刻都在编写代码，有些时间是在设计代码，而相当多的时间是在调试已经编写好的代码。自测试代码可以迅速减轻这种负担。

测试驱动开发（Test-Driven Development）的核心方法是在编写功能之前先编写测试，事实上代码应该与测试相匹配。

在测试类时，请务必测试类的公共接口；事实上，PHPUnit 不允许测试普通使用下的私有或保护方法。