图 1. 一个实际的 RCov 报告

        有了数字，就可以开始做一些关于需要进行多少测试的大致决定。对于 ChangingThePresent，我们已有的测试覆盖率统计数据有些浮动，但我们还是设置了 80% 和 85% 间的一个数字。由于一些重要的新特性尚在开发当中，所以覆盖率会临时有所下降。一旦我们将这些重要的新特性放到网上，覆盖率就会增加。当前的覆盖率为 81.7%。

        要注意，我们的覆盖率会和您的不完全一样。测试覆盖率的多少取决于开发团队中开发人员的经验、应用程序的复杂性、软件的容错程度以及业务对延时的容忍程度。如果构建的是一个飞机工程应用程序，那么就会需要进行更多的测试；如果要为 Facebook 构建只会流行一时的 Web 2.0 应用程序，而该应用程序两个月后就变得毫无价值（除非您能独辟蹊径），那么就可以进行较少的测试。所有我认识的优秀 Ruby 程序员都建议产品代码的覆盖率要高于 80%，有的甚至建议要尽力达到 100%。

        即使获得了 100% 的覆盖率，也不能保证测试就真正能够发挥作用。还必须考虑测试的类型，结合成功路径和边界条件，来获得尽可能好的覆盖率。

        了解用于判断需要进行多少测试的工具之后，我们就可以转换话题，谈谈测试速度。对 Rails 而言，数据库决定测试的速度。对受数据库支撑的测试工具的种种尝试总是因问题太多而受阻。其中两个最大的问题就是重复性和速度。从重复性的角度来看，在不更改数据库的情况下，要想构建一个很好的测试套件是非常困难的，但若更改数据库，测试数据也会更改，而这反过来又会改变测试的行为。另一个问题是速度。更改数据库的代价太高。

速度

        正如您所知道的，Rails 环境用固件解决重复性问题。开发人员一般会用测试数据设立固件。在处理每个测试用例前，Rails 测试框架会完全删除每个模型的数据并加载为每个测试用例所指定的每个固件。这样一来，每个测试用例都会有一个整洁的开始。但每个测试用例都有多个测试，并且每个测试都应完全独立于其他测试。为每个测试加载整套固件显然会非常慢。

        Rails 巧妙地解决了部分速度问题。在运行每个测试用例后，Rails 回滚所有数据库更改。回滚比重新加载所有固件数据要快得多。但数据库访问的代价却还是不容忽视。即使使用了回滚，受数据库支撑的测试仍很慢。如果测试太慢，开发人员就不愿意运行它们。如果测试得不到运行，就相当于没有什么实际用处。尽管 Rails 解决了重复性的问题，但它却不能完全解决速度问题。测试的速度将会影响未来几年的测试策略。

        另一个可选的方式是为测试使用内存数据库。通常 SQLite 要比 MySQL 运行得快很多。这种方式的缺点是可能无法在与生产系统相同的平台上运行测试。

        如果为数据库支撑使用了 ActiveRecord，则很可能会用受数据库支撑的测试进行所有的单元测试。这样一来，您将不得不接受低速做为开发的代价。但没有规定要求必须使用受数据库支撑的模型去做功能测试。现在很多 Rails 开发人员都使用 stub 和 mock 替代数据库，这就使功能测试变得十分轻快。