《重构 改善既有代码的设计》第4章 构筑测试体系——学习笔记

要正确地进行重构,前提是得有一套稳固的测试集合,以帮我们发现难以避免的疏漏。

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

1. 自测试代码的价值

“类应当包含他们自己的测试代码”。

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

自测试代码可以帮助我们快速的捕捉到bug,从而加快程序开发速度。

  • 一套测试就是一个强大的bug侦测器,能够大大缩减查找bug所需的时间

事实上,编写测试代码的最后时机是在动手编码之前。

测试驱动开发(Test-Driven Development TDD):先编写一个(失败的)测试,编写代码使测试通过,然后进行重构以保证代码整洁。这个“测试、编码、重构”的循环应该在每个小时内都完成很多次。

如果要重构一些没有测试的代码,那么在重构之前,得改造这些代码,使其能够自测试才行。

2. 第一个测试

  • 总是确保测试不应该通过时真的会失败
  • 频繁地运行测试。对于你正在处理的代码,与其对应的测试至少每隔几分钟就要运行一次,每天至少运行一次所有的测试。

一个真实的系统可能拥有数千个测试。好的测试框架应该能帮我们简单快速地运行这些测试。

图形化测试界面的确很棒,但并不是必需的。

3. 再添加一个测试

测试应该是一种风险驱动的行为,我测试的目标是希望找出现在或未来可能出现的bug。

  • 编写未臻完善的测试并经常运行,好过对完美测试的无尽等待。

5. 探测边界条件

  • 考虑可能出错的边界条件,把测试火力集中在那儿。
  • 不要因为测试无法捕捉所有bug就不写测试,因为测试的确可以捕捉到大多数bug。

任何测试都不能证明一个程序没有bug,但这并不影响“测试可以提高编程速度”。

当测试数量达到一定程度之后,继续增加测试带来的边际效用会递减;

如果试图编写太多测试,你也可能因为工作量太大而气馁,最后什么都写不成;

6. 测试远不止如此

测试本身是一个很重要的话题,它既是重构所必要的基础保障,本身也是一个有价值的工具。

单元测试负责测试一小块代码单元,运行足够快速。

测试覆盖率的分析智能识别出那些被测试覆盖到的代码,而不能用来衡量一个测试集的质量高低。

  • 每当你收到bug报告,请先写一个单元测试来暴露这个bug。

测试同样可能过犹不及。测试写得太多的一个征兆是,相比要改的代码,我在改动测试上花费了更多的时间——并且我能感觉到测试就在拖慢我。但目前业界大部分情况还是测试不足。

已标记关键词 清除标记
相关推荐
©️2020 CSDN 皮肤主题: 猿与汪的秘密 设计师:白松林 返回首页
实付 9.90元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值