追求代码质量: 通过测试分类实现敏捷构建

底层由运行时间最短的测试构成，可以想象的到，它们也最易于编写。这些测试占用的代码量也是最少的。顶层由更高级别的测试构成，这些测试占用了应用程序更大的部分。这些测试有一点难于编写，执行时间也要长得多。中间层是处于这两个极端中间的测试类型。

三种类型如下所示：

单元测试

组件测试

系统测试

让我们分别来看一下。

1. 单元测试

单元测试隔离地 验证一个或多个对象。单元测试不处理数据库、文件系统或任何可能延长测试运行时间的内容；因而，从第一天就可以编写单元测试。事实上，这也正是 JUnit 设计的确切目的所在。单元测试的隔离概念有无数的模拟对象库作后盾，这些库便利了将一个特定的对象从其外部依赖项中隔离出来。而且，单元测试能够在真正要测试的代码前编写 —— 由此有了测试优先开发 的概念。

单元测试通常易于编写，因为它们并不依靠于架构的依赖项，且通常运行得很快。缺点是，独立的单元测试只能覆盖稍显有限的代码。单元测试的重大价值在于：它们使开发人员能够在尽可能低的层面上保证对象的可靠性。

由于单元测试运行得如此之快且如此易于编写，代码库中应包含许多单元测试，并且应该尽可能多地运行它们。在执行构建时，应该经常 运行它们，不管是在机器上，还是在 CI 环境的上下文中（这意味着，代码一经签入 SCM 环境，就要运行单元测试）。

2. 组件测试

组件测试验证多个相互作用的对象，但它突破了隔离的概念。由于组件测试处理一个架构的多个层次，所以它们经常用于处理数据库、文件系统、网络元素等。同样，提前编写组件测试有点难，所以将其包含至一个真正的测试优先/测试驱动的场景中是很大的挑战。