前言

编写优良的测试程序，可以极大的提高我的编程速度，即使不进行重构也是一样如此。

自测试代码的价值

程序员花时间最多的是调试代码，修复代码很快，但是找出错误需要花费很多的时间。 每个类都应该有一个测试函数，并让它来测试自己这个类

确保所有的测试都完全自动化，让它们检查自己的测试结果

每次编译以后都进行测试，会发现生产性能大大提高。因为本来测试是可以正常运行的，但是这次执行测试的时候报错了，错误必定是前一次执行测试后引入的。由于每次测试都是不久之前，因此我知道错误的源头就是我刚刚写下的代码，由于我对代码记忆犹新，所以就能轻松的找到错误。
知道这一点以后，我不再等待每次增量结束，只要写好一点功能，就立即增加测试。每天我都会增加一些新功能，同时也添加相应的测试。

一套测试就是一个请打的bug侦测器，能够哒哒缩减查找bug所需要的时间

撰写测试代码的最有用时机是开始编程之前。当你需要增加特性的时候，先写相应的测试代码。听起来很不靠谱，其实，编写测试代码就是在问自己:添加这个功能需要做什么。编写测试代码使我们的注意力集中于接口而非实现。预先写好测试代码会为工作安上一个明确的结束标志，一旦测试代码正常运行，工作就可以结束了。

测试框架

单元测试的目的是为了提高程序员的生产力。单元测试是高度局部化的东西，每个测试类都隶属于单一包，它能够测试其他包的接口
功能测试用来保证软件能够正常运作，它们从客户的角度保障质量，不关心程序员的生产力，
一旦功能测试或最终用户找到软件中的bug，要除掉它，至少要做两件事。除了修改代码，还应该添加一个单元测试来复现

添加更多的测试

测试应该是一种风险驱动的行为，目的是希望找出现在或者未来可能出现的错误。所以我不会去测试哪些仅仅读或者写一个字段的访问函数，因为他们太简单了，不太可能出错。
测试的要诀就是:测试你最担心的出错的部分，这样你就能从测试工作中得到最大利益
测试的最重要的技巧就是“寻找边界条件”，比如最后一个字符，第一个字符，倒数第二个字符。边界值也包括寻找特殊的，可能导致测试失败的情况。
任何测试都不能证明一个程序没有BUG。我们应该把测试集中在可能出错的地方。观察代码，看哪里变得复杂；观察函数，思考哪些地方可能出错。
对象技术有个微妙处: 继承和多态会让测试变得比较困难，因为将有许多种组合需要测试。我并不总是使者测试所有可能组合，但是我会尽量测试每一个类，这个可以大大减少各种组合所造成的风险。花合理时间抓出大多数BUG好过穷尽一生抓出所有BUG

请构建一个良好的BUG检测器，并经常运行它，这对任何开发工作都将大有裨益，并且是重构的前提