DB2 与 Ruby on Rails,第 3 部分: 使用 DB2 和 Ruby on Rails 进行测试

Ruby on Rails 内置的测试特性和常用的 DB2 诊断工具

灵活的应用程序开发的一项关键需求是不断地进行代码集成,确保回归测试成功。Ruby on Rails 框架可以大大简化这个任务。与其他著名的快速应用程序开发环境一样,Ruby 支持单元测试和功能测试;但是它还能够通过智能化的模板自动生成大多数基础设施、目录、测试文件和测试用例。在 DB2 与 Ruby on Rails 系列 的第三篇文章中,我们将对第二篇文章中的 Team Room 演示程序应用 Rails 内置的测试框架。

John Chun, DB2 高级支持专家, EMC

John Chun 是 DB2 Advanced Support 小组从事应用程序开发和工具领域的专家。他在 IBM DBT 多伦多实验室工作了 7 年,负责解决涉及多种不同语言,例如 Java、C、C++、Perl、REXX、C# 等的 DB2 应用程序的问题。John 从事过很多涉及 DB2 CLI 和 OLEDB 驱动程序以及 .NET data provider 的项目。John 是一名 DB2 认证的解决方案专家和认证的 Websphere 管理员。



Alex Pitigoi, 咨询软件工程师, IBM

Alex Pitigoi 是 IBM 多伦多实验室的一名高级软件工程师。从 1998 年开始,他就从事 Information Management 中的各种软件开发项目,主要集中于 Web 技术和数据库管理。最近,他参加了 SQLModel 项目的开发,该项目现已被并入 Eclipse Data Tools Project,此外,他还参加了跨多个 IBM 数据服务器的数据库管理 Web Tools 的总体架构的开发。Alex 还从事过 DB2 Satellite Administration Center、IBM Express Runtime 方面的工作,并领导了为 DB2 发布的第一套 Web Tools。目前,他的工作重点是使 IBM 的数据服务器支持新的开放源代码技术(Ruby、Python、PHP)。



Naomi Ngan, 高级软件工程师, Autonomy

Naomi Ngan 在 2000 年获得了加拿大多伦多大学计算机科学和统计学的荣誉学位。毕业时,她加入了 IBM,负责解决应用程序开发环境中 IBM DB2 RDBMS 产品的缺陷和问题。在 IBM 呆了大约 4 年后,她进入位于加利福尼亚大学旧金山分校(UCSF)的 Ernest Gallo Clinic and Research Center,负责开发 Bioinformatics 软件。其工作包括设计和开发 Linux 和 Windows 平台上 XML 环境中的数据库对象、JSP、Java 独立应用程序和存储过程。目前,她是 Autonomy Corporation 的高级软件工程师,从事 J2EE 企业软件的开发。她在 DB2 应用程序开发和工具开发方面有着深厚的知识,并且拥有 DB2、XML、WebSphere 等领域的多个 IBM 和 Sun 开发人员认证。



Christine Law, DB2 高级支持专家, EMC

Christine Law 是 IBM 多伦多实验室的一名高级 DB2 专家,也是 IBM 认证的专家。她在 IBM 多伦多实验室负责解决 DB2 应用程序的问题和缺陷。她拥有丰富的 Linux、UNIX 和 Windows 平台上的应用程序开发经验,熟悉不同的编程语言和脚本编制语言,尤其擅长 JDBC、SQLJ、存储过程和嵌入式 SQL。最近,她的兴趣包括诸如 AJAX 和 Ruby 之类的开放源代码技术。



2007 年 12 月 03 日

简介

在 “DB2 与 Ruby on Rails” 系列的 第 1 部分 中,我们介绍了 IBM_DB Ruby 驱动程序、Rails 迁移和 Team Room 应用程序。在 第 2 部分 中,改进了现有的 Team Room 应用程序,学习了如何在 Rails 应用程序中利用 DB2® pureXML™ 支持。

既然 Team Room 应用程序已经扩展了,变得更加复杂了,就要确保这个应用程序的运行符合预期。很自然,下一步就是测试 Team Room 应用程序。本文讲解如何在 DB2 on Rails 环境中进行测试,以及如何在 Ruby on Rails 框架中编写测试。

Rails 框架为测试提供了内置的支持,可以方便地测试 web 应用程序。在 Rails 中,可以在编写和运行核心应用程序之后编写测试,也可以在编写应用程序的同时编写测试,甚至 可以在编写应用程序之前编写测试【这称为测试驱动的开发(TDD)】。

测试 Team Room 应用程序

在创建新的 Rails 项目时,Rails 会替您生成测试基础设施。如果进入 Rails Team Room 项目目录 D:\rails\teamroom\,就会看到 \test 子目录。在 \test 下面,会看到 5 个目录和一个 helper 文件:

清单 1. Test 目录的内容
/unit
/functional
/fixtures
/integration
/mocks
test_helper.rb

将您的所有测试放在 /test 目录中,特殊的测试根据性质和功能分别放在相应的子目录中。下面解释一下 /test 目录中的每个组件:

Unit

在 Rails 中,为测试模型编写的测试称为单元测试(unit test)。一般情况下,要为每个模型编写一个单元测试。在单元测试中,要测试所有可能破坏模型逻辑的东西。基本测试应该包括对检验代码和断言以及数据库操作(比如创建、读取、更新和删除,CRUD)的测试。

Functional

为测试控制器编写的测试称为功能测试(functional test)。它们在高于单元测试的层次上测试应用程序。同样,一般情况下要为每个控制器编写一个功能测试。功能测试的示例包括测试成功的 Web 请求、正确的页面重定向、正确的身份验证以及对特定动作的正确响应。

Fixtures

fixture 指定一个模型中的内容。在 fixture 中指定数据,并让 Rails 在运行单元测试时装载这些数据。这有点儿像 DB2 中的导入或装载函数。

Mocks

mock 是一个 “伪” 对象,它让我们能够集中精力测试 Rails 项目范围内的重要特性,而不必关注与无法控制的外部系统的交互。例如,当新文档添加到用户订阅的特定主题时,Team Room 应用程序会通过电子邮件通知他们。我们并不使用电子邮件检验系统来检验用户提供的地址是否是有效的电子邮件地址。相反,我们依靠电子邮件帐户提供商或域服务器提供的错误报告来检验用户提供的电子邮件地址。为了测试 Team Room 的通知功能,而不必访问外部网络,也不使用电子邮件检验系统,我们可以编写 mock 测试方法。

Integration

集成测试是涉及多个控制器和动作的测试。顾名思义,这种测试确保不同的控制器和动作按照预期的方式配合工作。集成测试一般比较完整,因为它们覆盖 Rails 应用程序中各个组件之间的高层交互。

test_helper.rb

test_helper.rb 文件建立多个测试用例共有的许多默认 Rails 测试行为。例如,在 test_helper.rb 中,RAILS_ENV 环境变量设置为 “test”,所以 Rails 会使用测试数据库进行测试(在 database.yml 文件中配置)。所有单元测试都装载 test_helper.rb 文件。在 test_helper.rb 中还可以定义定制的断言,这样同一个 Rails 应用程序中的多个测试就可以共享这些定制的断言。

设置各个数据库环境

在 “DB2 与 Ruby on Rails” 系列的 第 1 部分 中,我们编辑了 D:\rails\teamroom\config\database.yml 文件,从而建立到 DB2 XMLDB 开发数据库的连接。在这个 YAML 文件的 “development” 部分下面,有另外两个部分 “test” 和 “production”,我们还没有填写这些部分。显然,要在 “test” 部分中指定测试数据库环境,在 “production” 部分中指定生产数据库环境。在现实中,开发环境和测试环境可能指向同一个数据库,但是生产环境肯定应该与开发或测试数据库分开。现在,我们来创建 TESTDB 测试数据库,并在 database.yml 文件中设置测试环境。

创建 TESTDB 数据库:

db2 create db testdb using codeset utf-8 territory us

按照以下清单编辑 database.yml:

清单 2. database.yml 文件
# IBM DB2 Database configuration file
#
# Install the IBM DB2 driver and get assistance from:
# http://www.alphaworks.ibm.com/tech/db2onrails
development:
  adapter:      ibm_db
  database:     xmldb
  username:     user
  password:     secret
  schema:       teamroom
  application:  TeamRoom
  account:      devuser
  workstation:  devbox
# == remote TCP/IP connection (required when no local database catalog entry available)
# host:         bigserver     // fully qualified hostname or IP address
# port:         50000         // data server TCP/IP port number

test:
  adapter:      ibm_db
  database:     testdb
  username:     testuser
  password:     secret
  schema:       teamroom
  application:  TeamRoom
  account:      testuser
  workstation:  testbox

production:
  adapter:      ibm_db
  database:     proddb
  username:     produser
  password:     secret
  schema:       teamroom
  application:  TeamRoom
  account:      produser
  workstation:  prodbox

为了进行测试,我们希望确保测试数据库具有与开发数据库相同的表结构。我们不必管理那些装载数据库模式的 DDL 脚本,而是使用 Rake 命令帮助创建测试环境。运行 rake --tasks 命令,就会显示几个用来构建或清空测试数据库的命令:

清单 3. Rake --tasks 输出
rake db:test:clone             # Recreate the test database from the current 
                               # environment's  database schema
rake db:test:clone_structure   # Recreate the test databases from the development 
                               # structure
rake db:test:prepare           # Prepare the test database and load the schema
rake db:test:purge             # Empty the test database

注 1:要想执行 rake db:test:* 任务来处理 DB2,请按照 http://db2onrails.com/ 上描述的步骤修改 schema_dumper.rbdatabases.rake

备份旧文件并用以下目录中的两个新文件替换它们:

<ruby_path>\lib\ruby\gems\1.8\gems\activerecord-1.15.3\lib\active_record\schema_dumper.rb

<ruby_path>\lib\ruby\gems\1.8\gems\rails-1.2.3\lib\tasks\databases.rake

我们用 rake db:test:prepare 命令在数据库中建立表。这个命令会将开发数据库中的数据库模式复制到测试数据库中:

清单 4. rake db:test:prepare
D:\rails\teamroom> rake db:test:prepare
(in D:\rails\teamroom)

现在可以连接 testdb 数据库,检查所有表是否已经成功地创建了:

清单 5. testdb 中的表
D:\rails\teamroom>db2 list tables for schema teamroom

Table/View                      Schema          Type  Creation time
------------------------------- --------------- ----- --------------------------
DOCUMENTS                       TEAMROOM        T     2007-06-05-11.21.46.343002
SCHEMA_INFO                     TEAMROOM        T     2007-06-05-11.21.48.306001
SUBJECTS                        TEAMROOM        T     2007-06-05-11.21.46.633003
SUBJECTS_SUBSCRIPTIONS          TEAMROOM        T     2007-06-05-11.21.47.004000
SUBSCRIPTIONS                   TEAMROOM        T     2007-06-05-11.21.47.194005
USERS                           TEAMROOM        T     2007-06-05-11.21.47.595003
XML_CONTENTS                    TEAMROOM        T     2007-06-05-11.21.47.955001

  
  7 record(s) selected.

在测试数据库中定义了所有表之后,现在可以装载测试数据。尽管可以通过 SQL 插入或导入手工装载测试数据,但是更简单(也更容易管理)的方法是使用文本 fixture,稍后讨论这个问题。

Ruby 内置的单元测试

注 2:类声明中的 “<” 符号表示:符号左边声明的类是右边指定的类的子类。

Ruby(1.8.1 和更高版本)附带一个关键的库 test/unit。为了编写 Ruby 测试脚本,我们:

  1. 在 .rb 文件的顶部指定 “require 'test/unit'”。这个语句将装载 Test::Unit 模块。
  2. 在 require 语句后面,添加一个类声明,指出这个类是 Test::Unit::TestCase 的子类(见清单 6)。
清单 6. 为单元测试指定 “require 'test/unit'”
require 'test/unit'

class SubTestCase < Test::Unit::TestCase
  ...
end

在 Team Room 应用程序路径的 test\unit 子目录中,可以找到与所有(通过框架创建的)模型对象对应的 .rb 文件。这些文件名是在对象名后面加上 “_test”。

在 test\unit 子目录下创建测试脚本时,不需要指定 require 'test/unit' 语句。现有的 require 语句引用了 test_helper.rb,而 test_helper.rb 已经包含必要的信息。

清单 7. test\unit 路径列表
D:\rails\teamroom\test\unit>dir
 Volume in drive D has no label.
 Volume Serial Number is C8D3-5819

 Directory of D:\rails\teamroom\test\unit

06/05/2007  09:27 AM    <DIR>          .
06/05/2007  09:27 AM    <DIR>          ..
06/05/2007  09:27 AM               208 customer_info_test.rb
05/31/2007  07:42 PM               199 document_test.rb
06/02/2007  05:14 PM               251 subjects_subscription_test.rb
05/31/2007  07:42 PM               315 subject_test.rb
05/31/2007  07:42 PM             1,211 subscription_mailer_test.rb
05/31/2007  07:42 PM               207 subscription_test.rb
05/31/2007  07:42 PM               191 user_test.rb
05/31/2007  07:42 PM               204 xml_content_test.rb
               8 File(s)          2,786 bytes
               2 Dir(s)  15,359,959,040 bytes free

带 “test_” 前缀的方法

Ruby 中的所有测试方法名必须以 “test” 开头,否则测试框架就不知道它是一个测试。如果没有 “test” 前缀,它就被当作一般的 Ruby 方法,测试框架不会自动运行它。

清单 8. 一个简单的单元测试
require File.dirname(__FILE__) + '/../test_helper'

class Sub_Test < Test::Unit::TestCase
  def test_truth
    assert true
  end
end

现在可以将这个文件保存为 sub_test.rb。在执行时,它产生以下输出。

清单 9. 运行 sub_test.rb
D:\rails\teamroom\test\unit>ruby sub_test.rb
Loaded suite sub_test
Started
.
Finished in 0.631 seconds.

1 tests, 1 assertions, 0 failures, 0 errors

注 3:上面的测试的输出是一个 “.”。在 Rails 中,“.” 意味着通过测试或成功,“F” 意味着失败(意料外的结果导致断言失败),“E” 意味着错误(常常是 Ruby 本身的问题)。

上面这个简单的测试场景执行一个断言,由于使用了 “assert true” 语句,这个测试总会成功。断言就是测试,正如在下一节中看到的,有许多可以用来测试 Rails 应用程序的断言语句。

在 Rails 中,对于每个用 script/generate model、script/generate controller 和 script/generate scaffold 创建的模型和控制器,都在 test 子目录中创建一个对应的测试存根。在使用这些测试存根时,不需要指定 “require 'test/unit'”。

断言

断言检查应用程序或模块的前提条件和后续条件,确保它们处于有效的状态。Test::Unit 断言采用一种基本模式:第一个参数是预期的结果,第二个参数是实际结果。当预期值和实际值不相符时,生成一个消息来指出错误。

Test::Unit::Assertions 中可以找到核心 Ruby 断言的列表。

还有许多可用的断言。Module Test::Unit::Assertions Information 提供了相关信息。

正如前面提到的,断言用来确保有效状态。那么,有效状态如何定义?

在大多数情况下,有效状态由代码中的检验控制。

使用检验

在将输入数据存储到数据库之前,可以对它进行检验。为此,可以定义定制的检验或使用标准的检验集。对于标准的检验(比如检查属性的名称、长度和格式),可以使用 Active Record 提供的检验。

注 4: 所有 Active Record 检验方法名都以 “validates_” 开头,使用的参数是一个或多个属性名和/或一个或多个检验选项。

如果在模型中添加检验方法,那么在对象保存到数据库中之前就会执行检验。如果检验通过了,那么对象被写到数据库。如果检验失败,那么把与失败的对象检验方法相关联的错误消息添加到错误列表。可以显示这个列表,帮助用户采取适当的措施来纠正失败。

本文将用一些示例演示如何用 Active Record 的检验器集检验模型。

对于 Team Room 示例,假设我们希望对主题做以下检验:

  • 与这个主题相关联的所有文档对象都是有效对象
  • 主题名非空
  • 主题名的长度不超过 20 个字符

为了进行这些检验,可以使用一些标准的检验方法。我们在 app\models\subject.rb 中添加以下检验:

清单 10. app\models\subject.rb 中的检验
  validates_associated      :documents
  validates_associated      :subscriptions				
  validates_presence_of     :name
  validates_length_of       :name,
                            :maximum => 20,   # maximum 20 characters
                            :too_long => "is too long, maximum 20 characters"
  validates_numericality_of :size,            # value is numeric and only integer accepted
                            :only_integer => true,
                            :greater_than => 0                             
  validates_presence_of     :description
  validates_length_of       :tag,
                            :maximum => 10,   # maximum 10 characters
                            :too_long => "is too long, maximum 10 characters"

“validates_associated” 方法检查与这个主题相关联的所有文档是否有效。“validates_presence_of” 方法检查主题名是否非空。

使用 “validates_length_of” 方法检查主题名的长度是否不超过 20 个字符。使用 “maximum” 配置选项指定主题名的最大大小。“too_long” 选项指定主题名的长度超过 20 个字符时生成的错误消息,它用来替换 “message” 选项。在默认情况下,“too_long” 消息是 “is too long (maximum is %d characters)”。

注 5: validates_size_of 方法是 validates_length_of 方法的别名。

现在根据上面设定的规则检验主题输入数据。如果任何用户输入了有问题的数据,我们希望显示错误消息列表,让用户可以纠正输入数据。

下面是可以使用的 ActionView 方法:

  • error_message_on —— 返回指定的对象属性的错误字符串
  • error_messages_for —— 返回指定对象的错误列表

这里 可以找到关于这些方法的更多信息。

在 Team Room 示例中,如果希望列出为新主题输入的所有输入数据错误消息,可以在 app\views\subjects\_form.rhtml 的顶部添加以下代码。

清单 11. 输入数据错误消息
<%= error_messages_for 'subject' %>

这个方法调用将返回一个包含所有错误消息的 div(如果有错误消息的话),可以很容易地显示它:

图 1. 当输入的主题名太长时显示的错误消息
错误消息

这里 可以找到可以在类范围中定义的 Active Record 模型检验列表。

既然已经建立了主题模型检验,就可以使用断言实际测试上面的检验了。

使用断言

现在可以使用断言测试与 SUBJECTS 表相关联的模型。与 SUBJECTS 表相关联的模型之一确保用必需的有效信息填充这个表。对于避免在后端数据库上执行不必要的装载,这些检验非常重要。测试的检验见 \app\models\subject.rb(见 清单 10)。

“test_invalid_with_empty_values” 是一个简单的示例,它演示如何检查空值的错误条件。在 “test_invalid_with_empty_values” 方法中,测试空主题值是否导致错误。

清单 12. 测试方法 “test_invalid_with_empty_values”
require File.dirname(__FILE__) + '/../test_helper'

class SubjectTest < Test::Unit::TestCase

# Tests validation failure using empty values
  def test_invalid_with_empty_values
    subject = Subject.new
    assert !subject.valid?
    assert subject.errors.invalid?(:name)
    assert subject.errors.invalid?(:size)
    assert subject.errors.invalid?(:description)
  end
  ...

现在,再添加两个测试,一个测试检查有效的主题数据,另一个测试检查在指定不正确的 TAG 长度时是否显示期望的错误消息。

下面三个测试方法应该放在 test/unit/subject_test.rb 中:

清单 13. subject_test.rb 的测试方法
require File.dirname(__FILE__) + '/../test_helper'

class SubjectTest < Test::Unit::TestCase

# Tests validation failure using empty values
  def test_invalid_with_empty_values
    subject = Subject.new
    assert !subject.valid?
    assert subject.errors.invalid?(:name)
    assert subject.errors.invalid?(:size)
    assert subject.errors.invalid?(:description)
  end
  
# Tests validation using valid data
  def test_valid_subject
    subject = Subject.new(:name=>"Perl",
                          :size=>2,
                          :description=>"test",
                          :tag=>"123456789")
    assert subject.valid?
  end

# Tests invalid TAG length  
  def test_invalid_tag_length
    subject = Subject.new(:name=>"AJAX",
                          :size=>3,
                          :description=>"test",
                          :tag=>"abcdefghijklm")
    assert !subject.valid?
    assert_equal "is too long, maximum 10 characters",subject.errors.on(:tag)
  end 
end

如果以上单元测试成功,应该产生以下输出:

清单 14. 运行主题单元测试
D:\rails\teamroom>ruby test/unit/subject_test.rb
Loaded suite subject_test
Started
...
Finished in 13.891 seconds.

3 tests, 7 assertions, 0 failures, 0 errors

注 6: SubjectTest 是一个 TestCase,这个类继承自 Test::Unit::TestCase,可以包含一个或多个测试。测试用例的集合称为测试套件(TestSuite)。一个 TestCase 包含许多断言。

输出中的三个测试是指 subject_test.rb 文件中定义的三个测试,七个断言是指这个文件中的所有断言语句。正如前面在注 3 中提到的,“.” 是指成功的结果。

上面的 subject_test.rb 示例包含清单 15 所示的七个断言。

清单 15. subject_test.rb 中的断言
assert !subject.valid?
assert subject.errors.invalid?(:name)
assert subject.errors.invalid?(:size)
assert subject.errors.invalid?(:description)

assert subject.valid?

assert !subject.valid?
assert_equal "is too long, maximum 10 characters",subject.errors.on(:tag)

subject_test.rb 中的三个测试见清单 16。

清单 16. subject_test.rb 中的测试方法
test_invalid_with_empty_values
test_valid_subject
test_invalid_tag_length

用 fixture 进行测试

不需要在浏览器中手工输入值以测试 Rails 应用程序,而是可以使用测试 fixture 将示例数据装载到数据库表中。在运行测试之前,可以使用 fixture 用预定义的数据填充测试数据库。fixture 可以采用两种不同的格式:YAML 或逗号分隔的值(CSV)格式。因为 fixture 是独立于数据库的,所以可以使用同样的 fixture 针对不同的数据库系统测试 Rails 应用程序。

我们将使用 fixture 测试 Team Room 应用程序中的主题和订阅。对于我们的测试,使用一个 YAML fixture。为此,要编辑 /test/fixtures 目录中的 subjects.yml 文件。在 Rails 生成对应的单元测试时,它会创建一个空的 subjects.yml。当运行 ruby script/generate model 创建新模型,或运行 ruby script/generate scaffold 生成 scaffold 时,会自动生成 fixture 存根并放在 /test/fixtures 目录中。

注 7: fixture 文件名必须与数据库中的底层表名匹配。所以,为了将数据装载到 Team Room 的 SUBJECTS 表中,主题 fixture 文件必须命名为 subjects.yml。

注 8: 每个 YAML fixture 文件包含一个模型的数据。

我们编辑 subjects.yml 并填充 24 个不同的主题。在本文的 下载 一节提供的示例代码中可以找到 /test/fixtures/subject.yml。每个 fixture 有一个名称,后面是冒号分隔的键 - 值对。

subjects.yml 的内容示例:

清单 17. subjects.yml 的内容示例
# Read about fixtures at http://ar.rubyonrails.org/classes/Fixtures.html
photography:
  id: 1
  name: Photography
  size: 0
  description: Digital Photos, images
  tag: portraits

gardening:
  id: 2
  name: Gardening
  size: 0
  description: Gardening info
  tag: flowers

golf:   
  id: 3
  name: Golf
  size: 0
  description: Golf information, golf club, golf course discount available to members
  tag: golf

tennis:
  id: 4
  name: Tennis
  size: 0
  description: Tennis information, tennis club, tennis court bookings
  tag: tennis 

<etc ..>

Rails fixture 装载机制已经就位了,所以不需要添加额外的代码来装载测试数据。我们修改了清单 13 中的 /test/unit/subject_test.rb,添加了用 fixture 进行测试的代码。

清单 18. /test/unit/subject_test.rb 中与 fixture 相关的条目
require File.dirname(__FILE__) + '/../test_helper'

class SubjectTest < Test::Unit::TestCase
  fixtures :subjects

  # count the number of subject fixtures
  def test_subject_fixtures
    assert_equal 24, Subject.count
  end
  ...  
  # Previous test methods and assertions are listed below
  ...
end

在测试用例中的每个测试方法的开头,fixtures 方法自动地装载与模型名对应的 fixture。在默认情况下,:subjects 让 Rails 从 subjects.yml 文件装载示例数据。然后,添加一个 “test_subject_fixtures” 方法,测试所有 24 个主题是否都正确地装载了。

发出 ruby test/unit/subject_test.rb 命令运行测试。输出如下:

清单 19. 使用 fixture 的主题单元测试输出
D:\rails\teamroom>ruby test/unit/subject_test.rb
Loaded suite test/unit/subject_test
Started
....
Finished in 3.15 seconds.

4 tests, 8 assertions, 0 failures, 0 errors

假设启动了 WEBrick 服务器并作为已注册的用户登录,现在浏览到 http://localhost:3000/subjects/list。您会注意到,现在已经可以订阅 24 个主题。

图 2. 填充的主题条目
主题条目

有时候,可能需要通过 ERb(嵌入式 Ruby)使用动态 fixture 生成 fixture 数据。一个非常常见的例子是在运行测试时生成实际的时间戳。可以使用 <% ... %> 执行 Ruby 代码,使用 <%= ... %> 执行 Ruby 代码并显示结果。在后面的小节中解释功能测试和性能测试时,将会学习如何使用动态 fixture 和 ERb。

共享 fixture 并测试多对多关联

我们可以更进一步,使用 fixture 测试主题和订阅之间的关联。当然,可以浏览到 http://localhost:3000/subjects/list 并检查当前登录用户订阅的主题。然后,测试 Team Room 主题 - 订阅关联。但是,如果要测试许多用户订阅,涉及许多主题,那么这个任务就会非常繁琐。这意味着必须手工创建许多用户订阅,然后作为不同的用户登录,检查每个用户订阅的主题。

测试模型之间的多对多关系的有效方法是创建一个新的 fixture,其中包含联结表中的数据。在 第 2 部分 中,我们创建了 SUBJECTS_SUBSCRIPTIONS 表以表示 SUBJECTS 和 SUBSCRIPTIONS 表之间的多对多关系,并确保数据库是规范化的。现在编辑 /test/fixtures/subjects_subscriptions.yml 文件,用它将数据填充到 SUBJECTS_SUBSCRIPTIONS 表中:

清单 20. subjects_subscriptions.yml
# Read about fixtures at http://ar.rubyonrails.org/classes/Fixtures.html
# Refer to /test/fixtures/subjects.yml for more information
# Subject ID 2 = Gardening
subscription160_gardening:
  subscription_id: 160
  subject_id: 2
 
# Subject ID 3 = Golf  
subscription160_golf:
  subscription_id: 160
  subject_id: 3

这些数据意味着订阅 ID 为 160 的用户订阅了两个主题:Gardening 和 Golf。

要想测试主题和订阅的关联,就必须访问 SUBJECTS 和 SUBSCRIPTIONS 表以及联结表 SUBJECTS_SUBCRIPTIONS 中的数据。因此,在 /test/unit/subjects_subscription_test.rb 测试中,要装载这三个 fixture。

清单 21. fixture
class SubjectsSubscriptionTest < Test::Unit::TestCase
   fixtures :subjects_subscriptions, :subjects, :subscriptions
   [...]
end

这说明 fixture 非常强大,让我们可以跨多个测试用例共享测试数据。关于 fixture 的更多信息,参见 Ruby on Rails 文档中的 Class Fixtures

使用 mock 对象

mock 可以帮助我们忽略外部系统的影响,专心测试应用程序的核心功能。在用户向 Team Room 应用程序注册时,我们检查了电子邮件地址是否具有正确的格式,但是我们不知道提供的电子邮件地址是否是实际存在的。实际上,确认用户电子邮件地址的惟一方法是,向这个电子邮件地址发送电子邮件。如果电子邮件地址无效或不存在,就会从电子邮件提供商那里收到一个错误。为了测试这个失败的订阅通知发送场景,可以使用 mock。

例如,我们可以在测试环境中用 mock 模拟电子邮件发送方法。我们在 /test/mocks/test 目录中创建一个 email_provider.rb 文件,它定义我们要模拟的发送方法。mock 文件就位之后,Rails 首先装载 /test/mocks/test/email_provider.rb,然后查看 /app/models/email_provider.rb。

注 9: mock 文件的名称必须与 /app/models 目录中的模型完全相同。在 mock 文件中只需重新定义希望模拟的方法,所以不必在对应的 mock 文件中定义所有现有的方法。

/test/mocks/test/email_provider.rb 像下面这样:

清单 22. mock
require 'models/email_provider'
 
class EmailProvider
  def deliver(request)
    #Mock method
    :success
  end
end

mock 让我们能够集中精力测试 Team Room 应用程序的核心功能,而不需要为外部资源操心。

功能测试:对控制器进行测试

对 Rails 应用程序控制器进行测试的目的是,确保来自 Web 浏览器的所有请求都根据用户的输入得到了符合预期的响应,并产生适当的状态修改。所以,对于控制器中的每个动作,至少需要一个测试特定路径(URL)的测试用例,有时候可以用多个测试测试不同状态下的情况(例如,在用户已经通过身份验证和没有通过身份验证两种状态下,访问一个动作)。

为了体会一下功能测试,我们来考虑登录和注册动作涉及的 UsersController。在生成模型和控制器类时生成了相关联的 UsersControllerTest,它已经包含完整的设置模板和存根方法,只需稍加定制就能够处理执行路径。

清单 23. 用户控制器测试
require File.dirname(__FILE__) + '/../test_helper'
require 'users_controller'

# Re-raise errors caught by the controller.
class UsersController; def rescue_action(e) raise e end; end

class UsersControllerTest < Test::Unit::TestCase
  fixtures :users

  def setup
    @controller = UsersController.new
    @request    = ActionController::TestRequest.new
    @response   = ActionController::TestResponse.new

    @first_id = users(:first).id
  end
  [...]
end

基本方法 setup 对功能测试都需要的三个实例变量进行初始化:controller(要测试的控制器)、request(包含用户输入和 HTTP 头信息)和 response(包含来自模板的数据和状态码)。

对控制器进行测试的一个关键方面是相关联的 fixture,这个 fixture 为场景提供测试数据。这个控制器让我们有机会了解 fixture 中的一些动态特性的用法。在上面的测试用例中,提供一个已经通过身份验证的用户,需要用有效的数据填充 USERS 表,以便计算加密的密码。尽管加密的密码可以单独计算,而且只在 fixture 中直接使用,但是视图中使用的模板替换和部分工作是相似的,这会简化我们的任务。

清单 24. 用户 fixture
<% SALT = "tstsalt" unless defined?(SALT) >
first:
  id: 141
  usertype:  usr
  firstname: Homer
  lastname:  Simpson
  extension: '9955'
  email:     homer@simpson.org
  userid:    homers
  salt: <%= SALT %>
  hash_passwd: <%= User.encrypt('secret' , SALT) %>

最初的 test_index 测试用例需要分割为两个不同的测试用例,它们分别测试用户已经通过身份验证和没有通过身份验证两种情况下的请求处理:

清单 25. 测试用户控制器中的索引动作
  def test_index_without_user
    get :index
    assert_redirected_to :action => "login"
    assert_equal "Please sign-in" , flash[:notice]
  end

  def test_index_with_user
    get :index, {}, {:user_id => users(:first).id}
    assert_response 302
  end

为了测试这个控制器的索引动作(如果用户还没有通过身份验证,就重定向到登录页面),这个测试用例需要模拟来自浏览器的 GET 请求。为了生成 HTTP 请求,ActionController::Integration::Session 定义的 get 方法接受以下参数:URL、代表随动作传递的 HTTP 参数的散列值(在上例中为空)和填充会话所需的参数的散列值。现在我们只需要调用特定的测试用例:

清单 26. 运行用户控制器测试
D:\rails\teamroom>ruby test\functional\users_controller_test.rb -n test_index_with_user
Loaded suite test/functional/users_controller_test
Started
.
Finished in 0.719 seconds.
1 tests, 1 assertions, 0 failures, 0 errors

测试电子邮件通知和订阅确认

对电子邮件通知进行测试涉及单元测试(确保生成的电子邮件内容有效)和功能测试(确保在预期的时间发送电子邮件通知)。在 第 2 部分 中,基于 Action Mailer 实现了电子邮件通知控制器;对于这个控制器,应该找到生成的功能测试存根 SubscriptionMailerTest 并利用为通知动作所涉及的模型创建的 fixture。

为了对电子邮件通知和订阅确认进行单元测试,邮件器测试驱动要求为本地电子邮件发送配置 ActionMailer(delivery_method = :test),还要使用模型 fixture 设置调用通知和确认所需的对象。

清单 27. 邮件器功能测试设置
class SubscriptionMailerTest < Test::Unit::TestCase
  FIXTURES_PATH = File.dirname(__FILE__) + '/../fixtures'
  CHARSET = "utf-8"

  include ActionMailer::Quoting
  fixtures :users
  fixtures :subscriptions
  fixtures :subjects
  fixtures :documents

  def setup
    ActionMailer::Base.delivery_method = :test
    ActionMailer::Base.perform_deliveries = true
    ActionMailer::Base.deliveries = []

    @user = users(:first)
    @subscription = subscriptions(:one)
    @doc  = documents(:first)
    @subject = subjects(:ruby_on_rails)
    @subject.documents << @doc
    @subject.subscriptions << @subscription
  end
  [...]
end

然后,测试实现使用邮件器类创建电子邮件内容(create_notify),但是并不向 SMTP 服务器实际发送邮件,并通过使用断言检验生成的消息部分(例如,收件人、发件人、时间戳等等),包括消息体的某些部分。

清单 28. 通知电子邮件测试
  def test_notify
    response = SubscriptionMailer.create_notify(@doc)

    assert_equal("TeamRoom new shared document notification", response.subject)
    assert_equal("teamroom@developerWorks.ibm.com", response.from[0])
    assert_equal(nil, response.to)
    assert_equal("homer@simpson.org", response.bcc[0])
    assert_in_delta(Time.now, response.date, 1.0)
    assert_match(/A new document DB2onRails-logo.gif/, response.body)
    assert_match(/subject: Ruby on Rails/, response.body)
  end

使用相似的方式测试订阅确认电子邮件,创建并检验消息的内容。另外,邮件器的功能测试需要一个控制器测试用例,这个测试用例不发送电子邮件,而是将电子邮件消息追加到一个内存数组中(ActionMailer::Base.deliveries = [])。这样就可以检验发送的电子邮件数量,还可以检验每个电子邮件消息的内容。

性能测试

尽管在默认情况下在 test 目录中没有生成性能测试目录,但是开发人员可能希望评估一些应用程序性能指标。尽管在开发过程中太早关注性能是不明智的,但是当开发过程接近结束时,应该考虑一些性能场景来制定容量规划;在后续开发迭代中如果应用程序变慢了,应该进行一些回归测试。

为了讲解如何实现性能测试,我们来考虑一个场景:我们把 Team Room 应用程序部署在一个相当大的企业环境中,它可能承受过大的负载。我们像以前一样先设置一些测试数据,为此提供一组 fixture,这些 fixture 只在进行性能测试时装载,用来模拟对大量测试数据进行初始化时的情况。

清单 29. 用于大型测试数据集的另一个动态用户 fixture
<% SALT = "tstsalt" unless defined?(SALT) %>
<% 200.upto(1200) do |i| %>user_<%= i %>:
  id: <%= i %>
  usertype:  usr
  firstname: New<%= i %>
  lastname:  One
  extension: '9999'
  userid:    new<%= i %>
  email:     new<%= i %>@domain.net
  salt:      <%= SALT %>
  hash_passwd: <%= User.encrypt('secret' , SALT) %>
<% end %>

可以根据常规的使用场景考虑性能测试,然后扩展到模拟某些极端负载的大型测试数据集。这意味着这个测试与常规功能测试非常相似,但是测试用例在某个方面很极端。我们来考虑如何测试用户控制器和登录动作在极端负载下的表现。除了装载测试数据的位置(self.fixture_path)不同之外,测试用例的设置应该是相同的。

清单 30. 用户登录性能测试设置
class UserLoginTest < Test::Unit::TestCase
  self.fixture_path = Pathname.new(File.dirname(__FILE__)).parent + 
                                   'fixtures' + 'performance'
  fixtures :users

  def setup
    @controller = UsersController.new
    @request    = ActionController::TestRequest.new
    @response   = ActionController::TestResponse.new
  end
  [...]
end

现在,为了测试 Team Room 应用程序处理大量并发用户的能力,可以尝试让 fixture 中定义的所有用户同时登录,甚至可以为这些动作指定时间限制。在清单 31 中,我们用一个循环实现这种性能测试,然后关闭登录器,使用 Ruby 标准库基准收集时间估计值:

清单 31. 测试用户控制器在登录动作期间的性能
  def test_1000_login
    @controller.logger.silence do
      user_count = 0
      elapsed_time = Benchmark.realtime do
        1200.downto(200) do |id|
          user = users("user_#{id}")
          post :login, :userid => user.userid, :password => 'secret'
          user_count += 1
        end
      end
      assert_equal 1001, user_count
      assert elapsed_time < 10.0
    end
  end

再考虑一个更真实的性能场景:生成市场营销报告时,要执行一系列 XML 查询。我们把这个问题留给读者作为练习;如果读者希望把这个应用程序或相似的应用程序投入生产环境,就需要考虑这个问题。性能测试实现的一个重要特点是,使用常规的功能性和集成测试用例,但是采用大型测试数据集和沉重的负载。这种方式使性能回归测试的实现非常容易。

使用 Rake 运行应用程序测试

在使用 rails teamroom 命令开始创建 Team Room 应用程序时,生成了一个目录结构;更重要的是,还 “挂上” 了 Rails gem 内置的一组实用程序。Rails gem 是一个相当简单的组件,它在幕后无缝地集成所有其他组件;最明显的两个组件是 Active RecordAction View。同时,Rails gem 还通过强大的 Rake gem helper 使用框架解决所有 Web 应用程序共有的一些问题。

Rake 在 Ruby 中的作用相当于 make 实用程序。它通过预定义的任务(相当于 make 目标),为迁移、模式装载/转储、Rails gem 更新/冻结和文档创建提供快捷操作,还支持测试。在 Team Room 应用程序根目录中运行 rake --tasks,就可以看到 rake 提供的所有预定义任务。这些任务从一开始(在创建目录结构和 Rake 文件时)就已经注入 Team Room 应用程序中,然后共享 tasks/rails 库路径(这里包含预定义任务集)。

只需使用简单的 rake test 命令,就可以一起执行到目前为止构建的所有单元测试和功能测试;在开发周期中的任何时候都能够轻松地执行测试。还可以按类别运行测试;由于 Rails 应用程序采用标准的目录结构,所以很容易装载 test/unit 路径上定义的所有测试,见清单 32

清单 32. 运行 Team Room 应用程序的所有单元测试
D:\rails\teamroom>rake test:units
(in D:/rails/teamroom)
D:/ruby/bin/ruby -Ilib;test 
"D:/ruby/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake/rake_test_loader.rb" 
"test/unit/customer_info_test.rb" "test/unit/document_test.rb" 
"test/unit/subjects_subscription_test.rb" "test/unit/subject_test.rb" 
"test/unit/subscription_mailer_test.rb" "test/unit/subscription_test.rb" 
"test/unit/user_test.rb" "test/unit/xml_content_test.rb"
Loaded suite D:/ruby/lib/ruby/gems/1.8/gems/rake-0.7.2/lib/rake/rake_test_loader
Started
..........
Finished in 11.553 seconds.

调用 rake test:functionals 时会执行所有功能测试,rake 会把测试串联起来,覆盖整个测试集。

DB2 Rails 应用程序的问题诊断

在开发 Rails 应用程序时,可能会遇到出乎意料的结果或错误。在这种情况下,首先要检查 /log 目录(在我们的示例中,是 d:\rails\teamroom\log)中的日志文件。Rails 将每个环境的日志消息和错误写入它自己的日志。对于开发环境中的问题,应该查看 development.log;对于测试环境中的问题,应该查看 test.log。除了查看 Rails 日志并在应用程序本身中诊断问题之外,还可以使用 DB2 跟踪实用程序和日志进一步诊断 Rails 应用程序的问题。

CLI 跟踪

正如本系列的 第 1 部分 中提到的,ibm_db 驱动程序利用 IBM driver for Open Database Connectivity(ODBC) and Call Level Interface(CLI)连接 IBM 数据服务器。这意味着与 IBM 数据服务器的所有交互都要通过 IBM driver for ODBC and CLI,可以使用 CLI 跟踪捕获这些交互。CLI 跟踪捕获 Ruby 应用程序向 DB2 driver for ODBC and CLI 发出的所有 API 调用,并在日志中记录所有输入参数以及驱动程序返回给应用程序的值。因此,可以利用 CLI 跟踪检查输入和输出值,以及 Rails 框架在幕后生成的 SQL 语句。

Infocenter 可以找到启用 CLI 跟踪所需的步骤。

注 10: 因为 CLI 跟踪要写到磁盘,所以会影响应用程序的性能。另外,CLI 跟踪不是动态的,需要重新启动应用程序或者运行应用程序的 Web 服务器,跟踪(以及 db2cli.ini 中的其他 CLI 设置)才能生效。

对于检查应用程序发出的 SQL 语句和数据库返回的值,CLI 跟踪是非常有价值的工具。在 Team Room 应用程序中,大多数 SQL 语句是 Rails 生成的。下面的 CLI 跟踪输出显示在上载 XML 文档(见 图 2)时发送给 DB2 数据库的查询。可以看出,上载 XML 文档涉及在三个表中插入数据。

  1. 将内容类型、名称、平台、大小、主题、上载这个文件的用户的 id 以及更新和创建时间插入 documents 表。

    清单 33. CLI 跟踪:第 1 部分
    SQLExecDirect( hStmt=1:8 )
        ---> Time elapsed - +1.844000E-003 seconds
    ( pszSqlStr="INSERT INTO documents (content_type, name,
     platform, size, updated_at, 
    subject_id, user_id, created_at, data) VALUES('text/xml', 
    'CAN-Central.xml', 'Any', 
    125177, '2007-06-07 13:12:57', NULL, 100, 
    '2007-06-07 13:12:49', NULL)", cbSqlStr=225 )
    ( StmtOut="INSERT INTO documents (content_type, name, 
    platform, size, updated_at, 
    subject_id, user_id, created_at, data) VALUES(?, ?, ?, 
    125177, ?, NULL, 100, ?, NULL)" )
    ( Package="SYSSH200          ", Section=11 )
        sqlccsend( Handle - 84681200 )
        sqlccsend( ulBytes - 349 )
        sqlccsend( ) rc - 0, time elapsed - +1.991000E-003
        sqlccrecv( timeout - +0.000000E+000 )
        sqlccrecv( ulBytes - 188 ) - rc - 0, time elapsed - 
        +2.471000E-003
    ( Row=1, iPar=1, fCType=SQL_C_CHAR, rgbValue="text/xml" 
    - x'746578742F786D6C', pcbValu...
    ( Row=1, iPar=2, fCType=SQL_C_CHAR, rgbValue="CAN-Central.xml"
     - x'43414E2D43656E74726...
    ( Row=1, iPar=3, fCType=SQL_C_CHAR, rgbValue="Any" - x'416E79', 
    pcbValue=3, piIndicato...
    ( Row=1, iPar=4, fCType=SQL_C_CHAR, rgbValue="2007-06-07 13:12:57" 
    - x'323030372D30362...
    ( Row=1, iPar=5, fCType=SQL_C_CHAR, rgbValue="2007-06-07 13:12:49" 
    - x'323030372D30362...
        sqlccsend( Handle - 84681200 )
        sqlccsend( ulBytes - 223 )
        sqlccsend( ) rc - 0, time elapsed - +2.380000E-004
        sqlccrecv( timeout - +0.000000E+000 )
        sqlccrecv( ulBytes - 127 ) - rc - 0, time elapsed - +1.909000E-003
    
    SQLExecDirect( )
        <--- SQL_SUCCESS   Time elapsed - +1.504370E-001 seconds
    ...
  2. 插入 XML 文件的名称(与 documents 表中的 id 对应)和 XML 占位文档。

    清单 34. CLI 跟踪:第 2 部分
    SQLExecDirect( hStmt=1:8 )
        ---> Time elapsed - +5.003000E-003 seconds
    ( pszSqlStr="INSERT INTO xml_contents (name, document_id, 
    data) VALUES('CAN-Central.xml',
     101, '<ibm>@@@IBMXML@@@</ibm>')", cbSqlStr=108 )
    ( StmtOut="INSERT INTO xml_contents (name, document_id, data) 
    VALUES(?, 101, ?)" )
    ( Package="SYSSH200          ", Section=11 )
        sqlccsend( Handle - 84681200 )
        sqlccsend( ulBytes - 261 )
        sqlccsend( ) rc - 0, time elapsed - +1.799000E-003
        sqlccrecv( timeout - +0.000000E+000 )
        sqlccrecv( ulBytes - 137 ) - rc - 0, time elapsed - +1.865000E-003
    ( Row=1, iPar=1, fCType=SQL_C_CHAR, 
    rgbValue="CAN-Central.xml" - x'43414E2D43656E747261...
    ( Row=1, iPar=2, fCType=SQL_C_CHAR, 
    rgbValue="<ibm>@@@IBMXML@@@</ibm>" - x'3C69626D3E40...
        sqlccsend( Handle - 84681200 )
        sqlccsend( ulBytes - 221 )
        sqlccsend( ) rc - 0, time elapsed - +1.000000E-005
        sqlccrecv( timeout - +0.000000E+000 )
        sqlccrecv( ulBytes - 89 ) - rc - 0, time elapsed - +1.840000E-003
    
    SQLExecDirect( )
        <--- SQL_SUCCESS   Time elapsed - +8.456800E-002 seconds
    ...
  3. 然后是一个更新语句,它实际插入 XML 数据。

    清单 35. CLI 跟踪:第 3 部分
    SQLPrepare( hStmt=1:8 )
        ---> Time elapsed - +1.861000E-003 seconds
    ( pszSqlStr="UPDATE xml_contents SET (data) = (?) 
    WHERE id = 101", cbSqlStr=51 )
    ( StmtOut="UPDATE xml_contents SET (data) = (?) 
    WHERE id = 101" )
    ( Package="SYSSH200          ", Section=11 )
        sqlccsend( Handle - 84681200 )
        sqlccsend( ulBytes - 244 )
        sqlccsend( ) rc - 0, time elapsed - +1.000000E-005
        sqlccrecv( timeout - +0.000000E+000 )
        sqlccrecv( ulBytes - 120 ) - rc - 0, 
        time elapsed - +1.923000E-003
    
    SQLPrepare( )
        <--- SQL_SUCCESS   Time elapsed - +3.831300E-002 seconds
    ...
    SQLDescribeParam( hStmt=1:8, usPar=1, psSQLType= ...
        ---> Time elapsed - +2.315000E-003 seconds
    
    SQLDescribeParam( psSQLType=SQL_XML, puiParamDef=0, psScale=0, ...
        <--- SQL_SUCCESS   Time elapsed - +2.457500E-002 seconds
    
    SQLBindParameter( hStmt=1:8, iPar=1, 
    fParamType=SQL_PARAM_INPUT, fCType=SQL_C_BINARY, 
    fSQLType=SQL_XML, cbColDef=0, ibScale=0, rgbValue= ...
        ---> Time elapsed - +2.225000E-003 seconds
    
    SQLBindParameter( )
        <--- SQL_SUCCESS   Time elapsed - +3.743500E-002 seconds
    
    SQLExecute( hStmt=1:8 )
        ---> Time elapsed - +1.848000E-003 seconds
    E0D0A202020202020202020203C2F6974656D3E0D0A202020....., 
    pcbValue=125177 )
        sqlccsend( Handle - 84681200 )
        sqlccsend( ulBytes - 61440 )
        sqlccsend( ) rc - 0, time elapsed - +2.710000E-004
        sqlccsend( Handle - 84681200 )
        sqlccsend( ulBytes - 61440 )
        sqlccsend( ) rc - 0, time elapsed - +2.120000E-004
        sqlccsend( Handle - 84681200 )
        sqlccsend( ulBytes - 2450 )
        sqlccsend( ) rc - 0, time elapsed - +1.300000E-005
        sqlccrecv( timeout - +0.000000E+000 )
        sqlccrecv( ulBytes - 89 ) - rc - 0, 
        time elapsed - +2.345000E-003
    
    SQLExecute( )
        <--- SQL_SUCCESS   Time elapsed - +9.107600E-002 seconds
    ...
  4. 最后,使用插入语句相应地填充 SUBJECTS 表。

    清单 36. CLI 跟踪:第 4 部分
    SQLExecDirect( hStmt=1:10 )
        ---> Time elapsed - +2.166000E-003 seconds
    ( pszSqlStr="INSERT INTO subjects (name, size, tag, description) 
    VALUES('Marketing', 1, 'sales', '@@@IBMTEXT@@@')", cbSqlStr=100 )
    ( StmtOut="INSERT INTO subjects (name, size, tag, description)
     VALUES(?, 1, ?, ?)" )
    ( Package="SYSSH200          ", Section=14 )
        sqlccsend( Handle - 84681200 )
        sqlccsend( ulBytes - 263 )
        sqlccsend( ) rc - 0, time elapsed - +1.920000E-004
        sqlccrecv( timeout - +0.000000E+000 )
        sqlccrecv( ulBytes - 154 ) - rc - 0, time elapsed - 
        +1.823000E-003
    ( Row=1, iPar=1, fCType=SQL_C_CHAR, rgbValue="Marketing" 
    - x'4D61726B6574696E67', ...
    ( Row=1, iPar=2, fCType=SQL_C_CHAR, rgbValue="sales" - x'73616C6573',
     pcbValue=5, ...
    ( Row=1, iPar=3, fCType=SQL_C_CHAR, rgbValue="@@@IBMTEXT@@@" 
    - x'40404049424D5445 ...
        sqlccsend( Handle - 84681200 )
        sqlccsend( ulBytes - 182 )   
        sqlccsend( ) rc - 0, time elapsed - +3.160000E-004
        sqlccrecv( timeout - +0.000000E+000 )
        sqlccrecv( ulBytes - 89 ) - rc - 0, time elapsed - 
        +2.128700E-002
    
    SQLExecDirect( )
        <--- SQL_SUCCESS   Time elapsed - +1.243580E-001 seconds

DB2 跟踪

DB2 跟踪捕获所有可跟踪的内部 DB2 函数调用,可以用来诊断涉及 DB2 的应用程序问题。它提供应用程序执行时 DB2 内部活动的相关信息。DB2 跟踪的一些性质对于收集信息很有帮助。

  1. 可以动态地打开和关闭跟踪。不需要重新启动应用程序就能够启用和禁用跟踪。这意味着,如果知道准确的故障点,就可以在故障点之前启用跟踪,从而只收集相关的信息。
  2. DB2 跟踪信息可以存储在内存或磁盘中。
  3. 可以限制跟踪的范围,只跟踪特定的组件。

关于启用 DB2 跟踪的说明,请参考 Infocenter

当调试 Rails 应用程序的 DB2 问题时,在运行应用程序的客户机上同时收集 DB2 跟踪和 CLI 跟踪会很有帮助。

db2diag.log 和 db2diag 工具

db2diag.log 记录 DB2 遇到的错误和一些警告。通过查看 db2diag.log,可以了解在应用程序执行期间是否有任何 DB2 错误和警告。可以通过 dbm cfg 配置日志的敏感度,默认设置是 3。

对于 DB2 9®,可以使用分析工具 db2diag 对 db2diag.log 文件进行过滤和格式化。可以用它获得只针对特定数据库或时间戳值的日志记录。关于 db2diag 工具的更多信息,请参考 Infocenter

常见问题和提示

  1. 为了使用 ibm_db Ruby 适配器和驱动程序,是否需要安装 DB2 客户机? 是的。正如本系列的 第 1 部分 中指出的,IBM_DB 适配器(ibm_db_adapter.rb)直接依赖于 ibm_db Ruby 驱动程序,ibm_db Ruby 驱动程序利用 IBM driver for ODBC and CLI 连接 IBM 数据服务器。因此,至少需要 IBM DB2 Driver for ODBC and CLI,但是任何 DB2 9 FP2 或更高的客户机包(包含 CLI 驱动程序)都足以支持 IBM_DB 适配器连接所有 IBM 数据服务器。
  2. 在对 DB2 运行 Rails 应用程序时,遇到了以下错误: SQL0954C: Not enough storage is available in the application heap to process the statement. 正如 第 1 部分 中指出的,针对 DB2 9 的 Rails 应用程序需要的最小 APPLHEAPSZ 是 1024。连接您的数据库并获取配置参数,检查 APPLHEAPSZ。
  3. 要想以 IBM Ruby Driver 方式访问 DB2 i5 或 DB2 for z/OS 服务器,需要 DB2 Connect 吗? 是的,需要有 DB2 Connect,DB2 客户机才能连接 DB2 i5 或 DB2 for z/OS 服务器。在使用 IBM DB2 driver for ODBC and CLI 时,在驱动程序安装路径中需要一个有效的许可文件。
  4. 在尝试用 rake db:test:* 命令克隆出与开发环境相同的测试环境时,遇到了 rake aborted 错误。 检查 database.yml 文件。需要根据 database.yml 设置测试环境,database.yml 是 rails 命令生成的默认配置。另外,一定要按照注 1 中的说明更新两个文件。
  5. 遇到了在 IBM_DB 适配器的最新版本中已经修复的问题。但是,gem list --local 命令显示已经安装了 IBM_DB 适配器的最新版本。 确保在 <ruby_path>\lib\ruby\gems\1.8\gems\activerecord-1.15.3\lib\active_record\connection_adapters 或 UNIX® 上的相似路径中没有 ibm_db_adapter.rb 的副本。 最新版本 IBM_DB gem 中的 ibm_db_adapter.rb 应该只安装在 GEM_HOME 路径 <ruby_path>\lib\ruby\gems\1.8\gems\ibm_db-<version>-mswin32\lib\active_record\connection_adapters(或 UNIX 上的相似路径)中。这是装载到 Rails 环境中的唯一 IBM_DB 适配器。
  6. 在即将发布的 Rails 1.2.4 中,将会取消 config.connection_adaptersRAILS_CONNECTION_ADAPTERS。因此,不再需要按照 第 1 部分 中描述的手工步骤在 Rails 框架中的连接适配器列表中注册 “ibm_db”。使用 gem install ibm_db 命令安装 IBM_DB 适配器之后,Rails 环境马上就能够找到并装载它。

结束语

Rails 框架内置的测试支持让测试工作变得轻松多了!每个 Rails 应用程序都在 config/database.yml 文件中定义了测试、开发和生产环境,因此可以为不同的用途设置不同的数据库。在最初创建新的 Rails 项目时,Rails 会替我们生成测试基础设施。对于您创建的每个模型和控制器,都会创建对应的测试存根。对 Rails 模型进行单元测试,然后通过功能测试和集成测试在更高层次上确保 Rails 应用程序符合设计预期。可以使用 fixture 指定测试用的数据;mock 对象让我们能够集中精力测试应用程序的核心功能,而不必为网络连接或外部系统操心。这些特性都是 Rails 内置的,这让测试变得非常方便。


下载

描述名字大小
Team room 示例代码Teamroom3.zip10KB

参考资料

学习

获得产品和技术

讨论

条评论

developerWorks: 登录

标有星(*)号的字段是必填字段。


需要一个 IBM ID?
忘记 IBM ID?


忘记密码?
更改您的密码

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件

 


在您首次登录 developerWorks 时,会为您创建一份个人概要。您的个人概要中的信息(您的姓名、国家/地区,以及公司名称)是公开显示的,而且会随着您发布的任何内容一起显示,除非您选择隐藏您的公司名称。您可以随时更新您的 IBM 帐户。

所有提交的信息确保安全。

选择您的昵称



当您初次登录到 developerWorks 时,将会为您创建一份概要信息,您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。

昵称长度在 3 至 31 个字符之间。 您的昵称在 developerWorks 社区中必须是唯一的,并且出于隐私保护的原因,不能是您的电子邮件地址。

标有星(*)号的字段是必填字段。

(昵称长度在 3 至 31 个字符之间)

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件.

 


所有提交的信息确保安全。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Information Management, Open source
ArticleID=272541
ArticleTitle=DB2 与 Ruby on Rails,第 3 部分: 使用 DB2 和 Ruby on Rails 进行测试
publish-date=12032007