你总能编写更多测试。但是很快就会发现，在所有想得出来的测试中只有很小一部分是真正有用的。你想要的是编写你觉得能运作但却失败的测试，或者你觉得必将失败但却成功了的测试。另外一种思考方式是从成本/收益的关系上去考量。你想要编写能够给你反馈信息的测试。 | ||
| --Erich Gamma | ||
当需要对软件的内部结构进行更改时，你实际上是要在不影响其可见行为的情况下让它更加容易理解、更加易于修改，测试套件对于安全地进行这些所谓的重构而言是非常宝贵的。否则，你可能在重组过程中将系统搞坏而不自知。
在使用单元测试来确认重构的转换步骤中确实保持原有行为并且没有引入错误时，以下情况有助于改进项目的编码与设计：
所有单元测试均正确运行。
代码传达其设计原则。
代码没有冗余。
代码所包含的类和方法的数量降至最低。
当需要向系统内添加新的功能时，首先为其编写测试。然后，当测试能够正常运行就标志着开发完成了。下一章将详细讨论这种做法。
当看到缺陷报告时，你可能会有尽快修复错误的冲动。经验表明，这种冲动不是好事，因为修复一个缺陷时很可能导致另外一个缺陷。
下列操作可以帮你压住冲动：
确认能够重现此缺陷。
在代码中寻找此缺陷的最小规模表达。例如，如果在输出中有一个数字看起来不对，那么就寻找算出此数字的那个对象。
编写一个目前会失败而缺陷修复后将会成功的自动测试。
修复缺陷。
寻找缺陷的最小可靠重现使你有机会去真正检查缺陷的原因。当修复了缺陷之后，所编写的测试则有助于提高缺陷真正被修复的几率，因为新加入的测试降低了未来修改代码时又破坏此修复的可能性。而之前所编写的所有测试则降低了在不经意间导致其他问题的可能性。
进行单元测试带来了很多好处：
总之，进行集成单元测试降低了任何修改的成本与风险。这使得项目能够更快并且更有信心地进行[...]重大架构改良[...]。 | ||
| --Benjamin Smedberg | ||