- 想要重构就需要有一个可靠的测试环境. 每个类都应该有一个测试函数并以它来测试自己这个类.
- 这个测试还应该有自己的期望输出, 然后在测试中进行自我校验, 确保所有测试都能完全自动化.
- 频繁地运行测试, 每完成一小段功能就测试一次, 甚至重构途中的每一小节就测试一次, 由于自动化所以不会太费心, 这样可以及时在思路还没断开的时候轻松解决错误
- 编写测试的最佳时机就是开始编程新特性之前. 先写测试代码再进行开发, 这也使得我们能先设计好接口, 明确功能再进行开发, 也给工作设下了明确的阶段标识, 一旦测试通过, 一个阶段就结束了.
- 频繁测试是极限编程的标识, 只有频繁的测试才能加速我们的开发, 少数的测试就能大大提高开发效率.
- 测试一种方法是对每个类都有自己的testing函数负责校验功能, 但是这样不太好操控, 更好的方法是建立一个独立类, 在一个外部框架中进行测试
- 我目前不写java所以这个东西的实际使用对我意义不大, 但是还是很有启发
- 写一个专门的测试框架来负责各种测试时间计算, 测试结果输出等操作
- 然后测试框架调用子测试函数/类, 负责将测试分块, 每一块都有自己的理想输入和输出
- 子测试类内部调用各种待测函数
- 为了时间考虑, 应该将测试分块, 每次只测试一小段即可, 这样才比较快. 但是最好每天都进行一次完整测试, 测试最重要的就是不要嫌麻烦.
- 测试机制自己也需要有测试, 但是不用太复杂因为测试本身的逻辑就不是很复杂
- 开发者重要的是单元测试, 也就是测试各种接口. 功能测试是测试人员负责的
- 测试应该是一种风险驱动的行为, 目的是希望找出现在或未来可能出现的错误, 所以太简单的功能是不需要测试的, 只测试最容易最担心出错的部分
- 编写不完整的测试并实际应用, 好过等待一份完整的测试而迟迟不动手
- 要有特殊的命名习惯, 所有测试函数都以test起头然后作为用例被包含
- 测试的重要技巧是寻找各种边界条件, 专注于如何破坏自己的代码
- 测试不单单要测试正确情况, 也要测试意外情况是否被正确捕获
- “花合理时间抓出大多数bug”要好过“穷尽一生抓出所有bug”. 应该把测试集中在关键地方, 别让编写测试占用太多时间
- 不用测试每种多态组合, 尽量测试每个子类就ok了