捕获 bug
我还记得当我第一次得到自动测试的 bug 时的情况。在一次大会上，当我做完叫做 Bitter Java 的 演讲之后，Mike Clark（Java 社区的自动测试大师，性能调整工具 JUnitPerf 的作者（请参阅 参考资 料），现在是 Ruby on Rails 专家）走近我。Mike 告诉我有一种方法可以通过自动测试改进我的演讲。 在那次大会的剩余时间里，我跟着他四处走，看到了我能看到的尽可能多的他的测试会议。我开始使用他 推荐的技术，并对把红条（代表测试失败）变成绿条（代表测试通过）上了瘾。自动测试改变了我思考软 件开发的方式。
Java 社区绝对有自动测试的 bug。坦白地说，我们别无选择。竞争压力迫使许多公司编写越来越多的 代码，而测试人员越来越少，同时每个开发人员的又必须有更高的生产率。如果不进行自动测试，得到测 试的内容就会更少，面对现代应用程序不断增长的复杂性，较少的测试不是一个可行的选择方案。
在过去十年中，我们已经看到了对测试工具和技术的研究。JUnit 和 TestNG 都是支持自动单元测试 的优秀工具，而且由日常的开发人员所驱动。Selenium 是改进集成和功能测试的工具。一套称作敏捷技 术 的新开发过程告诉人们要更加重视自动测试，不要太多地依赖正式的设计工具，将它们作为提高质量 的惟一工具。Java 社区已经走了很长的路。 (请参阅 参考资料，获得这里讨论的工具与技术的附加信息 。)
其他编程社区也有 bug 工具， 其中一些社区使用的自动测试要比 Java 开发人员还有多，他们使用 自动测试经验有完全不同的原因：
Smalltalk 程序员使用自动测试已经几乎有 30 年的时间了，所以通过动态类型化语言使用的一些技 术更加先进。
集成框架的开发人员的优势是了解框架元素的结构和组合。有些框架，例如 Ruby on Rails，能够生 成测试用例，而且在默认情况下提供测试特性。
具有高级元编程（metaprogramming）能力的语言，例如 Ruby and Lisp，允许使用其他语言不支持的 一些测试技巧，例如更容易访问 mock 对象。
在这一篇和下一篇文章中，将全面理解在 Ruby on Rails 集成开发框架中的测试方式。第 1 部分侧 重于测试模型对象，并提供一些从 Rails 获得启发的策略，可以用这些策略使 Java 单元测试更有效。 第 2 部分把更多时间花在功能测试和集成测试上。作为 Java 程序员，您对一些概念可能比较熟悉，特 别是在测试的时候，而其他一些概念可以拓展您的理解。
补漏
在这个系列的 前一期 中，了解了动态类型化会带来某些 bug 种类，静态类型化语言将在编译时捕捉 到这些 bug。清单 1 的 Ruby 代码片段包含四个不同的 bug，这四个 bug 在运行时之前都不会显露出来 ：
清单 1. 带 bug 的 Ruby 代码
position = "2" #string, where a number was intendedposition = positoin + 4 #position is misspelled, evaluates to 0puts "The position is:" + position.to_string #The method should be to_s
如果编译器能够捕捉 bug，那么这类 bug 解决起来是小菜一碟，但是如果依赖解释器，那么管理这些 bug 就困难得多。为了处理这些微妙的错误，动态语言的用户长期以来一直依赖于自动测试。在进行测试 的时候，比起其他语言，动态语言及其集成环境在一般意义和特殊意义上都具有显著的优势：
语言更简洁。测试基本上是脚本编程，许多最好的脚本语言都是动态类型化的。
集成环境支持的假设可以让集成测试更容易，也可能更强大。在 Rails 环境中将看到一些示例。
动态语言允许使用更松散的耦合，使一些测试格式更容易实现。
在了解动态语言开发人员为什么这么热衷于测试之后，现在是构建一个需要一些真正测试的实际应用 程序的时候了。
构建一个快速 Rails 应用程序
为了进展得快些，我采用了一个保存山地摩托车路线数据库的 Rails 应用程序。我将模型的几个测试 放在一起。如果想和我一起编写代码，那么所有需要的工具就是一个数据库引擎（我使用的是 MySQL）和 Ruby on Rails 1.1 或更新版本（请参阅 参考资料）。第一步是创建 Rails 项目。在命令提示符下输入 rails trails 命令，清单 2 显示了命令和结果：
清单 2. 构建 Rails 应用程序
> rails trailscreate create app/controllerscreate app/helperscreate app/modelscreate app/views/layouts...partial results deleted...create test/fixturescreate test/functionalcreate test/integrationcreate test/mocks/developmentcreate test/mocks/testcreate test/unitcreate test/test_helper.rb...partial results deleted...create config/environment.rbcreate config/environments/production.rbcreate config/environments/development.rbcreate config/environments/test.rb...partial results deleted...create log/server.logcreate log/production.logcreate log/development.logcreate log/test.log
Rails 除了生成空项目什么都没做，但是可以看到它正在为您工作。清单 2 创建的目录中包含：
应用程序目录，包括模型、视图和控制器的子目录
单元测试、功能测试和集成测试的测试目录
为测试而明确创建的环境
测试用例结果的日志
因为 Rails 是一个集成环境，所以它可以假设组织测试框架的最佳方式。Rails 也能生成默认测试用 例，后面将会看到。
现在要通过迁移创建数据库表，然后用数据库表创建新数据库。请键入 cd trails 进入 trails 目录 。然后生成一个模型和迁移（migration），如清单 3 所示：
清单 3. 生成一个模型和迁移
> script/generate model Trail exists app/models/ exists test/unit/ exists test/fixtures/ create app/models/trail.rb create test/unit/trail_test.rb create test/fixtures/trails.yml create db/migrate create db/migrate/001_create_trails.rb
注意，如果使用 Windows，就必须在命令前加上 Ruby，这样命令就变成了 ruby script/generate model Trail。
如清单 3 所示，Rails 环境不仅创建了模型，还创建了迁移、测试用例和测试 fixture。稍后将看到 fixture 和测试的更多内容。迁移让 Rails 开发人员可以在整个开发过程中处理数据库表中不可避免的 更改（请参阅 跨越边界：研究活动记录）。请编辑您的迁移（在 001_create_trails.rb 中），以添加 需要的列，如清单 4 所示：
清单 4. 添加列
class CreateTrails < ActiveRecord::Migration def self.up create_table :trails do |t| t.column :name, :string t.column :description, :text t.column :difficulty, :string endend def self.down drop_table :trails endend
您需要创建和配置两个数据库：trails_test 和 trails_development。如果想把这个代码投入生产， 那么还需要创建第三个数据库 trails_production，但是现在可以跳过这一步。请用数据库管理器创建数 据库。我使用的是 MySQL：
清单 5. 创建开发和测试数据库
mysql> create database trails_development;Query OK, 1 row affected (0.00 sec)mysql> create database trails_test;Query OK, 1 row affected (0.00 sec)
然后编辑 config/database.yml 中的配置，以反映数据库的优先选择。我的配置看起来像这样：
清单 6. 将数据库适配器添加到配置中
development: adapter: mysql database: trails_development username: root password: host: localhosttest: adapter: mysql database: trails_test username: root password: host: localhost
现在可以运行迁移，然后把应用程序剩下的部分搭建（scaffold）在一起：
清单 7. 迁移和搭建
> rake migrate...results deleted...> script/generate scaffold Trail Trails...results deleted... create app/views/trails ...results deleted... create app/views/trails/_form.rhtml create app/views/trails/list.rhtml create app/views/trails/show.rhtml create app/views/trails/new.rhtml create app/views/trails/edit.rhtml create app/controllers/trails_controller.rb create test/functional/trails_controller_test.rb ...results deleted...
再次注意，Rails 已经为您创建了测试用例。框架不仅为这个简单的小程序生成了视图和控制器，而 且还生成了有助于测试用户界面的功能性测试。
对 Rails 应用程序进行单元测试
现在是运行一些测试的时候了。请看第一个测试，它已经在 test/unit/trail_test.rb 中写好了：
清单 8. 第一个测试
require File.dirname(__FILE__) + '/../test_helper'class TrailTest < Test::Unit::TestCase fixtures :trails # Replace this with your real tests. def test_truth assert true endend
确实，这个测试用例算不了什么，但您可以从中看出如何构架测试代码，而且自己的测试用例的模板 也已经就位。请运行测试，如清单 9 所示（包括结果）：
清单 9. 运行第一个测试
> ruby test/unit/trail_test.rb Loaded suite test/unit/trail_test Started EE Finished in 0.027314 seconds. 1) Error: test_truth(TrailTest): ActiveRecord::StatementInvalid: Mysql::Error: #42S02Table 'trails_test.trails' doesn't exist: DELETE FROM trails...results deleted...
测试用例失败，但是请看输出。第一行执行测试。第三行 EE 显示测试的结果。如果测试用例通过， 会得到 “.” 字符。如果测试用例产生错误，会看到 E。如果某个断言不是 true，那么将看到 F。接下 来，可以看到所请求的全部测试都将完成，以及完成这些测试需要的时间。最后，将看到每个失败的详细 原因。在这个示例中没有表，这是有一定原因的，因为在测试数据库中还没有创建任何表。通过将开发方 案复制到测试环境，再重新运行测试，可以修复错误，如清单 10 所示：
清单 10. 复制方案，重新运行测试
> rake clone_schema_to_test (in /Users/batate/rails/trails)> ruby test/unit/trail_test.rb Loaded suite test/unit/trail_test Started . Finished in 0.038578 seconds. 1 tests, 1 assertions, 0 failures, 0 errors
这样更好。但是测试还是太简单，所以是构建一个真正的测试用例的时候了。请添加下面这个新测试 用例 test_truth，如清单 11 所示：
清单 11. 添加测试用例
def test_truth assert true end def test_new trails = Trail.find_all Trail.new do |trail| trail.name = "Barton Creek" trail.description = "A little water in the Spring. You'll get wet." trail.difficulty = "medium" trail.save end bc = Trail.find_by_name("Barton Creek") assert_equal "medium", bc.difficulty assert_equal trails.size + 1, Trail.find_all.size end
这个代码惊人的紧凑。只需要键入上述代码以及两个断言，就可以操纵持久模型。这种经济的投入正 是脚本语言在其他环境中如此流行的原因。测试也是需要经济投入的地方。
现在可以运行测试用例，您将看到两个新断言显示在测试报告中。使用 Ruby 时，只需保存并编译测 试即可。清单 12 显示了测试运行的结果：
清单 12. 测试结果
> ruby test/unit/trail_test.rb Loaded suite test/unit/trail_test Started . Finished in 0.038578 seconds. 1 tests, 1 assertions, 0 failures, 0 errors bruce-tates-computer:~/rails/trails batate$ ruby test/unit/trail_test.rb Loaded suite test/unit/trail_test Started .. Finished in 0.182043 seconds. 2 tests, 3 assertions, 0 failures, 0 errors
Fixture 和回滚
有三个问题影响了对数据库支持代码的测试。它们都与两个特性有关：性能和重复性。与内存中的操 作相比较，数据库调用的性能是非常低的。如果测试运行需要太长时间，那么您可能就不想运行它们了。 另一个问题是一个测试用例对另一个测试用例的影响。因为数据库调用在性质上是持续的，所以要把一个 测试在数据库中的变化与另一个数据库中的隔离开。最后的问题是前两个问题的组合。为了让数据库测试 用例可重复而增加设置和拆卸的负担时（为每个新的测试用例添加记录、运行测试并删除这些记录），带 来的开销可能是让人无法接受的。与这种开销相比，测试用例开销简直是小巫见大巫。
Ruby on Rails 用 fixture 和事务回滚来帮助解决这些问题。在 Rails 中，一个 fixture 就是一个 包含测试用例数据的文件。在创建这个简单应用程序时，同时还创建了一个开发数据库和一个测试数据库 。创建开发数据库是很正常的；但是您可能不想让生产代码和开发环境共享同一个数据库。而创建测试数 据库因为另一个原因也很重要。每个测试都在测试用例开始时装入 fixture 中的测试数据。然后，测试 用例对数据库进行修改，并测试这些修改的结果。最后，Rails 回滚这些变化，将数据库返回到测试方法 运行之前的状态。
现在要制作一个测试 fixture 并为它编写一个测试。请编辑 test/fixtures/trails.yml 文件，添加 一个记录，如清单 13 所示：
清单 13. 添加记录
first: id: 1 name: "Emma Long" description: "A real bike breaker." difficulty: "hard" another: id: 2 name: "Bear Creek" description: "Too many downed trees." difficulty: "easy"
清单 13 使用叫做 YAML 的语言，这个语言描述结构化的数据（请参阅 参考资料）。此文件对空格很 敏感，所以该当用空格代替制表符并完全按原样键入数据项时，请确保删除了所有尾部空格。
同样，还要把这个测试用例添加到 trails_test.rb 中：
def test_find assert_equal "Emma Long", Trail.find(1).name assert_equal "easy", Trail.find(2).difficulty end
同样，可以用 5 个 passing 断言运行这些测试。如果您愿意，还可以按名称引用每个 fixture。例 如，要根据名为 first 的 fixture 来创建对象，可以使用 Ruby 代码 trails[:first]。让 fixture 对 所有测试用例或只对需要它们的测试用例可用，这极大地简化了创建或毁坏数据库数据所需要的代码。
在 Java 编程中测试
知道了测试在其他语言中如何发生，就可以改进在 Java 平台上进行测试的方式。具体地说，使用这 些想法中的一项或多项可以对测试产生显著而直接的影响：
可以把测试用例的生成添加到任何现有代码生成当中。Ruby on Rails 通过在默认情况下创建一些简 单的测试用例来取得了巨大优势，您也可以这么做。
可以用事务-回滚技术让数据支持的测试运行得更快。Spring 框架有一些现有的拦截器，可以让这项 技术易于使用。
实际上可以用动态语言驱动测试。Jython、Ruby 和 Groovy 是三个实际可能。
如果觉得愿意采用其他语言进行测试，那么可以使用某种 JVM 语言，例如 JRuby（请参阅 参考资料 ）。JRuby 还没有高级到可以运行 Ruby on Rails，但是它是 Java 应用程序卓越的测试平台。只是作为 尝试，JRuby 的开发人员 Charles O’Nutter 提供了以下测试 EJB 的示例：
清单 14. 用 JRuby 测试 EJB 组件
require 'test/unit' require 'java' include_class "my.pkg.EJBHomeFacTory" class TestMyBean < Test::Unit::TestCase def test_finder wh = EJBHomeFacTory.widget_home w = wh.find_by_color("blue") assert_not_nil(w) end def test_widget wh = EJBHomeFacTory.widget_home w = wh.find_by_name ("superWidget") assert_equal("blue", w.color) assert_equal(14, w.id) end end
可以看到，用 Ruby 编写执行 Java 代码的测试用例实际上非常容易。在这个示例中，Ruby 代码发现 一个 EJB 组件，并为用户返回的 bean 提供了一些断言。测试用例当然比多数 Java 测试都容易，使用 Ruby 编写测试用例是一个获得更高的生产率和速率的一种好方法。我还看到针对 Jython 或 Groovy 的 类似策略（请参阅 参考资料）。
第 2 部分将进一步深入查看 Rails 的测试，包括运行更高层次测试（叫做功能测试和集成测试）的 代码。
仿佛松树就是一位威风的将军，守护着国家的国民。
