Working effective with legacy code读书笔记- 单元测试

 

大部分关于单元测试的概念的共同部分是单元测试由一组独立的测试构成，其中每个测试针对一个单独的软件组件。但是对于组件的定义就各不相同了。在单元测试中，我们通常将最原子的行为单元看作组件。通常来说，在过程化的语言中，我们将一个方法看成一个单元；在面向对象的语言中，我们将一个对象类看成一个单元。

我们能否只测试一个方法或者一个类？在我们的程序中，方法和方法之间总是存在大量的相互调用。在面向对象的程序中，类也不是孤立存在的，我们也很少有不使用其他的类的类。（就算有，也大部分是数据类等）。

但是，独立的测试是单元测试中的一个很重要的部分。和那些覆盖了很多功能和代码的“大测试”相比，“大测试”有如下的问题：

• 错误定位：由于覆盖的功能和代码太多，很难定位是什么导致的测试失败。

• 执行时间：“大测试”通常需要比较长的时间来运行，因此程序员通常不会经常执行它。我们前面说过，我们可以修改一小段代码，然后运行测试，如果有问题，那么问题就是出现在这一小段代码中，我们可以很容易的定位问题并解决。但是如果测试需要很长的时间来执行，我们就会尽量避免频繁的执行它。我们总是修改很多代码，然后执行测试；这个时候出现了问题，就很难定位了。

• 代码覆盖：如果我们添加了一段新的代码，我们需要做很多的工作来创建比较高层的测试来覆盖它。

一个好的单元测试必须具备两个品质：

• 运行很快

• 能够帮助定位错误

什么叫快呢？作者的意思是能够在 1/10秒内完成的测试才叫做单元测试。（汗，我工作的系统中，很多单元测试都达不到这个标准）。为什么定一个这样的标准？假设我们有一个系统，一共有 1000个类，每个类有 10个方法需要测试，如果每个测试需要 0.2秒完成，那么完成整个系统的单元测试需要多久？ 1000×10×0.2=2000秒，半个多小时，这样没有人会经常运行整个单元测试。那么单元测试就失去了意义。但是如果每个测试能够在 0.1秒内完成，那么运行整个单元测试只需要 10多分钟，那么可能平时我只运行测试中的一小部分，但是我会每半天就运行一次整个单元测试。