修改代码的艺术读书笔记002——带着反馈工作

一、对系统改动的两种方式

在书中，作者很有意思的描述了对系统改动的两种改动方式：

1. 1. 编辑并祈祷。
   2. 覆盖并修改。

实际上来说，几乎大部分人都是按照第一种做法来做的。先确保理解代码，然后找到改动点，编辑之后，再花大量的时间来确认改动是否生效，改动是否破坏了其他功能。这里存在的问题，首先是，这种方式意味着修改都要非常小心，并且，当这个改动对系统侵入性较强的时候，还需要倍加小心，不然出错的可能性会更大；即使如此，改动的安全性并不仅仅意味着小心，没有正确的工具和技术，小心也起不了多大作用。

覆盖并修改则是另外一种方式。覆盖软件的意思是用测试来覆盖它，当对一组代码有一组良好的测试时，我们就可以放心地对它进行修改，并快速检验出好坏。相比传统的测试做法不同的是，传统的测试总是在开发后进行，而测试员的工作安排有可能导致整个反馈周期长得难以接受，只要有1-2轮返工，工期就很可能被延期。

对于覆盖软件的测试，单元测试比系统层面的回归测试也要更好，一分钟可以得到的反馈，相比等几个小时，显然是要更有效率的。对一段代码，如果被一组单元测试彻底覆盖了，那在接下来对这段代码进行重构或修改的时候，我们可以在很短的时间内得到足够多的反馈，大大增强了重构的安全性。

当然，和第一种方法相比，覆盖软件起码在表面上也意味着更多的工作量。但是从日常开发工作中，我们很容易得到这样的经验：开发工作量大在大部分时候都不是我们项目延期和加班的原因，而程序中层出不穷难以调试的bug，才是导致我们工作进展困难的罪魁祸首。

二、什么是单元测试

单元测试一般是针对一个系统最为原子的行为单元的测试。比如过程式语言中的函数或者说面向对象语言中的类。

在单元测试中，测试隔离性是一个重要方面，覆盖代码更广泛功能的测试也很重要，但是较大型的测试存在一些问题：

1. 难以定位错误。测试离被测对象更远，关联的其他因素越多，当测试失败时，就越难定位问题的所在。
2. 执行时间太长。较大型的测试往往需要更多的时间来运行，这也意味着需要更多的时间来得到反馈。而因为花费的时间多，开发人员就越不愿意多次执行。
3. 覆盖面不足。因为测试离测试对象太远，往往很难确定某段代码和测试用例之间的关系，即使通过工具找出来未被覆盖的代码块，依然需要花费大量的脑筋去考虑如何增加用例去覆盖改代码块。

好的单元测试应该具有以下品质：

1. 运行快。
2. 能够帮我们定位问题所在。

有些测试很容易和单元测试混淆起来，比如以下测试就不是单元测试，即使我们通常也会在单元测试用具中编写这些测试：

1. 和数据库有交互；
2. 进行了网络通讯；
3. 调用了文件系统；
4. 需要做特定准备（如编辑配置文件）才能运行；

二、高层测试及其作用

单元测试非常有用，但高层测试也有一定作用。高层测试是指覆盖了某个场景和交互的测试，可以用来确定一组类的行为。单元测试所能覆盖的只是类本身，如果和其他类有依赖，我们还要尽可能解开。这样带来的一些问题就是，有时候我们没办法确定两个类的交互形式就是我们所想要的，高层测试可以覆盖到一组类和它们之间的交互。

三、测试覆盖

对于遗留代码的测试覆盖，可以使用以下步骤，关于步骤具体的实施方法，是后续的内容：

1. 1. 确定修改点；
   2. 找出测试点；
   3. 解依赖；
   4. 编写测试；
   5. 修改重构