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

编写组件测试要花更长的时间，因为它们比单元测试所涉及的东西要多。另一方面，由于其宽广的范围，它们实现了比单元测试更广的代码覆盖率。当然它们也要花更多时间运行，所以同时运行很多的组件测试会显著地 增加总的测试时间。

许多框架有助于测试大型架构组件。DbUnit 是这类框架的一个典型例子。DbUnit 能够很好地处理在测试状态间建立一个数据库这样的复杂性，因而它会使编写依赖于数据库的测试变得较为简单。

当构建的测试延长时，通常都预示着包含了一个大型的组件测试套件。由于这些测试比真正的单元测试运行时间长，因而不能一直运行它们。相应地，在 CI 环境中这些测试可以至少 每小时运行一次。在签入任何代码前，也应该总在一个本地开发人员机器上运行这些测试。

验收测试
验收测试 和功能测试类似，不同之处在于，理想情况下，验收测试是由客户或最终用户编写的。正如功能测试一样，验收测试也像最终用户测试那样进行。Selenium是一个备受瞩目的验收框架，它使用浏览器测试 Web 应用程序。Selenium 在构建过程中可以是自动运行的，就像 JUnit 测试一样。但 Selenium 是一个新平台：它不使用 JUnit，在使用方式上也不相似。

3. 系统测试

系统测试端到端地 验证一个软件应用程序。因而，它们引入了一个更高级别的架构复杂度：整个应用程序必需为要进行的系统测试而运行。如果是一个 Web 应用程序，您就需要访问数据库以及 Web 服务器、容器和任何与运行系统测试相关的配置。其遵循这样的原则，即大多数系统测试都在软件生命周期的较后周期中编写。

编写系统测试是个挑战，也需要大量的时间来实际地执行。而另一方面，就架构性代码覆盖率来讲，系统测试是一件极为划算的事情。