-
在Linux平台上安装和配置Redhat系列下安装rubyOnRails的生产环境（转）
2010-07-15 17:00:27
-
`gem_original_require': no such file to load -- zlib (LoadError)(转发)
2010-07-15 13:02:57
-
JDK1.6在LINUX下的安装配置（转发）
2010-07-15 10:39:00
-
在 Ruby on Rails 中进行单元测试第二部分（转发）
2010-07-14 17:06:20
转发：http://soft.zdnet.com.cn/software_zone/2007/0901/482327.shtml
关于本系列
在 跨越边界 系列中，作者 Bruce Tate 提出了这样一个观点：如今的 Java 程序员可以通过学习其他方法和语言得到很好的其他思路。自从 Java 明显成为所有开发项目的最佳选择以来编程前景已经改变。其他的框架正影响构建 Java 框架的方式，从其他语言学到的概念可以影响您的 Java 编程。您编写的 Python（或 Ruby、Smalltalk ... ）代码可以改变您处理 Java 编码的方式。
本系列为您介绍与 Java 开发根本不同，但也可以直接应用于 Java 开发的编程概念和技术。在一些例子中，需要对技术进行集成以利用它。在另外一些例子中，您将能够直接应用这些概念。单独的工具不及其他语言和框架能够影响 Java 社区中的开发人员、框架甚至基本方法的思想那么重要。
在这由两部分组成的迷你系列的 第 1 部分 中，了解了如何用动态语言促进单 元测试。本文将展示集成环境在功能测 试和集成测试中的优势。单 元测试包括对小的代码片断（例如方法）的测 试，而且经常要把它们与周围的元素隔离开。功能测 试和集成测试所测 试的应用程序部分越来越多。功能测 试用于测试单一特性（通常涉及一个接口）、执行任务的业务代码，以及与中间件服务交互的代码（例如数据库）。集成测 试用于测试应用程序的多个不同特性。（功能测 试在不太严谨的情况下通常也被称为集成测 试。）
Java 开发人员在解决单 元测试问题上已经获得了令人注目的成果，但在集成测 试上则没有带来太多令人兴奋的消息。多数 Java 测 试框架（如 JUnit 或 TestNG）主要侧重于单 元测试。Java 编程中缺乏集成测 试框架的一个原因是缺乏集中的架构或开发哲学。在后面的小节中，我将继续使用 Ruby on Rails 示例，这次的重点放在功能测 试和新的 Rails 集成测 试框架上。您将看到，在使用集成测 试框架时，进行测 试要容易得多。
如果还没有阅读 第 1 部分，那么请先阅读它。然后，如果想跟随这篇文章一起编写代码，那么请确保您已经获得 一个可工作的 Rails 应用程序。在第 1 部分中，实现了一个简单的单 元测试和几个 fixture。如果您跟随第 1 部分一起编写了代码，但是记不清是否使应用程序处于工作状态，那么您可以利用测 试用例，先切换到项目目录，然后运行
rake即可。清单 1 显示了我的结果：
清单 1. 用 rake 运行所有测试
> bruce-tates-computer:~/rails/trails batate$ rake
(in /Users/batate/rails/trails)
/usr/local/ror/bin/ruby -Ilib:test
"/usr/local/ror/lib/ruby/gems/1.8/gems/rake-0.7.0/lib/rake/rake_test_loader.rb"
"test/functional/trails_controller_test.rb"
Loaded suite /usr/local/ror/lib/ruby/gems/1.8/gems/rake-0.7.0/lib/rake/rake_test_loader
Started
EEEEEEEEEEEEEEEE
Finished in 0.070797 seconds.
1) Error:
test_create(TrailsControllerTest):
Errno::ENOENT: No such file or directory - /tmp/mysql.sock
/usr/local/ror/lib/ruby/gems/1.8/gems/activerecord-1.14.0/
lib/active_record/vendor/mysql.rb:104:in 'initialize'
/usr/local/ror/lib/ruby/gems/1.8/gems/activerecord-1.14.0/
lib/active_record/vendor/mysql.rb:104:in 'real_connect'
/usr/local/ror/lib/ruby/gems/1.8/gems/activerecord-1.14.0/
lib/ active_record/connection_adapters/mysql_adapter.rb:331:in 'connect'
...results deleted...
8 tests, 0 assertions, 0 failures, 16 errors
/usr/local/ror/bin/ruby -Ilib:test "/usr/local/ror/lib/ruby/gems/1.8/gems/rake-0.7.0/
lib/rake/rake_test_loader.rb"
rake aborted!
Test failures
(See full trace by running task with --trace)
可以看到有一些问题存在：
rake生成了 16 个错误。跟踪显示，Rails 无法建立连接。我忘记启动数据库引擎了。我将启动数据库引擎，然后再次运行rake。这次我得到了清单 2 所示的结果：
清单 2. 在 rake 内通过测试
rake
(in /Users/batate/rails/trails)
/usr/local/ror/bin/ruby -Ilib:test
"/usr/local/ror/lib/ruby/gems/1.8/gems/rake-0.7.0/lib/rake/rake_test_loader.rb"
"test/unit/trail_test.rb"
Loaded suite /usr/local/ror/lib/ruby/gems/1.8/gems/rake-0.7.0/lib/rake/rake_test_loader
Started
...
Finished in 0.09541 seconds.
3 tests, 5 assertions, 0 failures, 0 errors
/usr/local/ror/bin/ruby -Ilib:test
"/usr/local/ror/lib/ruby/gems/1.8/gems/rake-0.7.0/lib/rake/rake_test_loader.rb"
"test/functional/trails_controller_test.rb"
Loaded suite /usr/local/ror/lib/ruby/gems/1.8/gems/rake-0.7.0/lib/rake/rake_test_loader
Started
........
Finished in 0.169756 seconds.
8 tests, 28 assertions, 0 failures, 0 errors
这样就好多了。测 试正常运行，而我们准备构建更多测 试用例。如果仔细查看清单 2 就会发现，
rake生成了两组结果。第一组（第 1 部分的单 元测试）看起来应当熟悉。下一组是从框架中自动生成的功能测 试。
在查看测试代码之前，需要对 Rails 的用户界面层有更好的理解。在第 1 部分中，用
script/generate scaffold Trail Trails生成框架代码时，Rails 根据数据库的内容为应用程序创建了一个控制器和系列视图。控制器的代码位于 app/controller/trails_controller.rb，视图则全部位于 app/views/trails 下的不同目录中。这个应用程序包含：- 默认 Web 页面实现，显示路线（trail）列表（叫做
list） - 路线的细节信息的显示页面
- 路线的通用表单
- 创建或编辑路线的页面
要了解这些是如何组合在一起的，请参见 trails_controller.rb 中的
list方法，如清单 3 所示：
清单 3. app/controllers/trails_controller.rb 中的部分代码清单
def list
@trail_pages, @trails = paginate :trails, :per_page => 10
end
传入的超文传输协议（HTTP）请求进入控制器。（HTTP 是支持浏览器、Rails 和所有基于浏览器的应用程序的底层协议）。在这篇文章后面，您将看到功能测 试如何通过使用 HTTP 命令来调用功能测 试用例。清单 3 的代码设置了 Rails 显示线路的分页列表时需要的实例变量。视图需要一个分页器对象，即 Rails 分配给
@trail_pages的分页器对象，还需要@trails中的路线列表。默认情况下，Rails 使用与控制器方法相同的名称呈现视图。要查看视图，请参阅 app/views/trails/list.rhtml 中的表格定义，如清单 4 所示：
清单 4. list.rhtml 的部分代码清单
<table>
<tr>
<% for column in Trail.content_columns %>
<th><%= column.human_name %></th>
<% end %>
</tr>
<% for trail in @trails %>
<tr>
<% for column in Trail.content_columns %>
<td><%=h trail.send(column.name) %></td>
<% end %>
<td><%= link_to 'Show', :action => 'show', :id => trail %></td>
<td><%= link_to 'Edit', :action => 'edit', :id => trail %></td>
<td><%= link_to 'Destroy', { :action => 'destroy', :id => trail },
:confirm => 'Are you sure?', :post => true %></td>
</tr>
<% end %>
</table>
Rails 中的视图策略是：创建一个简单字符串，然后做一些替换。这个策略叫做建模，它构成了大多数现代 Web 框架的基础，包括 Java 框架（例如 Tapestry、JavaServer Faces(JSF)、JavaServer Pages (JSP) 和 WebWork）。在这个示例中，Rails 做了以下工作：
- 执行
<%和%>之间的代码段（被称为语句），并用代码 段的执行输出替代这一部分。语句可能不存在。
- 执行
<%=和%>之间的代码段（被称为表达式）， 并用代码段返回的值替代这一部分。
- 处理布局、偏好、帮助程序以及其他类型的代码片断时。这些特性允许使用不同的复合部件构建复杂的 Web 页面。在这里，我就不对细节做过多介绍了。
在有了模板策略之后，现在再来看一下 清单 4。您可以看到访问活动记录
Trail模型并用<% for trail in @trails %>命令在@trails中的每条路线上循环的 list.rhtml 视图。（您已经填充了控制器中的@trails实例变量）。对于每条路线，该视图都将得到Trail.content_columns， 它是trails_development数据库中trails表的列的列表。然后，该视图通过在列表中的每个列上进行循环，提供数据库中每一列的值。trail.send(column_name)命令把name、difficulty和description方法发送给trail。现在是在屏幕上查看结果的时候了。如果回忆一下，应当记得您已经在第 1 部分的示例中键入了一些 fixture 形式的测 试数据。要把它们加载到开发环境（fixture 默认装入测 试环境）中，则只需键入
rake load_fixtures即可。启动 Rails 服务器（在 Unix 上用script/server，在 Windows 上用ruby script/server）， 把浏览器指向 localhost:3000/trails/list 就可以看到结果。在这个 URL 中，trails 是控制器的名称，list 是动作的名称，由list控制器方法实现。图 1 显示了结果：
清单 1. 列出路线
正如所期望的那样，可以看到一个包含每条路线的名称、说明和难度的表。接下来，我将介绍 Rails 的功能测 试框架如何只通过一条 HTTP
put命令访问 Web 页面。
回忆一下就可以知道，Rails 单 元测试只处理模型。Rails 中的功能测 试调用 Web 页面，然后检查结果，从上到下地测 试某一特性（包括模型、视图和管制器）。这种级别的集成测 试很重要，因为可以确保系统的主要元素之间的交互与您对所提供的每个特性的预期一样。
Rails 的每个功能测 试用例都要进行 HTTP
put和get。它们调用控制器的动作；控制器访问模型和 视图，并呈现 Web 页面和结果。要获得详细的工作示例，请参见 Rails 在框架中生成的测 试用例：
清单 5. 来自 test/functional/trails_controller_test.rb 的 test_list
def test_list
get :list
assert_response :success
assert_template 'list'
assert_not_nil assigns(:trails)
end
清单 5 中的测 试用例利用
get :list命令执行了一个简单的 HTTPget。然后，测 试用例运行了三个断言：assert_response :success：HTTP 命令成功完成。assert_template 'list'：控制器动作呈现list模板。assert_not_nil assigns(:trails)：控制器把@trails实例变量分配给一些非 null 的值。
使用单元测 试框架，如果断言为 ture，没有错误出现，那么测 试用例就通过；否则，测 试用例失败。
test_list测 试用例可以声明:success响应，但是它应当声明:redirect（代表 HTTP 重定向）、:missing（代表not_found），或代表单个 HTTP 返回代码的整数。请参阅 参考资料，获得 HTTP 返回代码的详尽列表。现在请看test_create， 它使用了一个 HTTPput。请将test_create更改成如清单 6 所示：
清单 6. 测试表单
def test_create
num_trails = Trail.count
post :create, :trail => {:name => "Hermosa Creek", :description =>
"Lots of altitude, all down", :difficulty => "Medium"}
assert_response :redirect
assert_redirected_to :action => 'list'
assert_equal num_trails + 1, Trail.count
end
trails_controller_test.rb 中自动生成的这个测 试用例的版本包括
post :create, :trail => {}，它调用create方法，空哈希表表示新路线。这个代码应当创建一条新路线，该路线有一个所有属性都为 null 的Trail对象。清单 6 修改了代码，以传递代表路线属性的哈希映射表。这个哈希映射表接口对于在测 试框架中指定对象而言非常有用。然后，测 试用例用Trail模型确保创建了新路线。清单 5 和清单 6 中的测 试用例不像第 1 部分中的单 元测试那样处理每个细节。但是它们可以保证调用了业务逻辑，保证控制器逻辑没有检测到任何错误，并保证得到了正确的 HTTP 响应。
功能测试用于测 试单一特性，而集成测 试可能触及许多不同的页面。例如，购物车单 元测试可以测 试出您可能通过模型 API 将一件商品添加到购物车中。购物车的功能测 试可以确保您能够通过登录某一 Web 页面将商品添加到购物车中。而集成测 试则可以保证能够登录、添加商品和结账。
在 “Running Your Rails App Headless”（请参阅 参考资料）中，Mike Clark（Rails 社区领先的测 试专家之一）详细介绍了集成测 试框架。开始进行讨论时，他介绍了如何运行没有 Web 页面的（即 headless）应用程序。这项功能使得搜集编写集成测 试的足够信息变得更容易。从 Rails 1.1 开始，可以直接从控制台调用控制器。不需要浏览器，只要调用
app对象的put和get方法，就可以访问应用程序的 Web 页面。请启动控制台，键入清单 7 中的命令，通过 HTTP
get发出列表动作：
清单 7. 从控制台使用 Rails 集成测试框架
> script/console Loading development environment.
>> app.class
=> ActionController::Integration::Session
>> app.get('trails', 'list')
=> 200
>> app.get("trails/list")
=> 200
>> app.response =~ /Barton Creek/
=> false
>> app.response =~ /Emma Long/
=> false
>> app.response.body =~ /Emma Long/
=> 331
>>
在清单 7 中，从控制台以两种形式发送请求，调用
trails控制器的list动作。然后，通过与正则表达式/Emma Long/匹配，可以看到生成的 HTML 页面中包含 Emma Long（一条路线）。您可以继续运行post和get：
清单 8. 通过 post 实现删除
>> app.post("trails/destroy/1")
=> 302
>> Trail.find_all
=> [#<Trail:0x25a8e34 @attributes={"name"=>"Bear Creek", "id"=>"2",
"description"=>"Too many downed trees.", "difficulty"=>"easy"}>]
>> Trail.find_all.size
=> 1
>> app.response.redirect_url
=> "http://www.example.com/trails/list"
>>
通过控制台集成测 试 API，现在有了构建集成测 试的足够信息。请使用
script/generate integration_test DestroyAndShow生成一个集成测试，并将它编辑成清单 9 那样：
清单 9. test/integration/destroy_and_show.rb
require "#/../test_helper"
class DestroyAndShowTest < ActionController::IntegrationTest
fixtures :trails
def test_multiple_actions
get "trails/list"
assert_response :success
post "trails/destroy/1"
assert_response :redirect
assert_nil(response.body =~ /Emma Long/)
assert_equal(2, Trail.find_all.size)
follow_redirect!
assert_response :success
get "trails/show/2"
assert_response :success
end
end
这个示例使用的集成框架与前面通过 Rails 控制台使用的框架相同，使用的断言模型也与功能测 试和单元测 试框架的模型相同。可以用
rake运行测 试用例，也可以单独运行每个测 试用例。通过以一致的方式使用控制台和集成框架，可以尝试应用程序的各个方面，获得控制台中的结果，并用这些结果在自动测 试用例中提供您的断言。
现在可以开始查看集成框架中的集成测 试有什么不同了。对于这个示例，可以使用 fixture，它们在集成测 试框架中工作。断言和表示想法的方式（例如请求和响应）都有统一的形式。
基本 Ruby 语言中的某些功能让 Rails 的测 试更强大。可以使用 Ruby 做类似 mock 和存根所做的事。在编写这篇文章时，我正在使用 Rails 进行一些自动集成测 试。我有一个依赖于当前日期的类。我只是打开了用于
Date的现有 Ruby 类，并重新定义了today方法，让它返回Date.civil(2, 2, 2006)，如清单 10 所示：
清单 10. 用 Rails 创建存根
require "#/../test_helper"
class Date
def self.today
return Date.civil(2006, 2, 2)
end
end
class NameOfTest ...continue test case here...
对于我的测试用例，我什么都不需要做。现在，不论测 试用例什么时候运行，
today都会是美国的假日土拔鼠日。只使用了五行代码，我就有了一个可工作的存根。在这个示例中，这个 mock 对象只能用于测 试用例。如果需要将这个 mock 对象用于多个测 试用例，那么可以给这个 mock 对象添加测 试和模拟的代码，并重新使用它。总之，我对 Ruby 的测 试体验的评价是：非常必要（因为动态语言容易出错的特性），并且更强大。其中部分力量来自通过 Rails 使得代码生成、断言、数据库支持，以及诊断工具无缝地在一起工作的集成体验。
但是 Java 技术确实有自己的优势。在将测 试集成到开发环境方面它做得更好，它还有更好的持续集成工具。也可以找到模拟最常见企业特性的更多框架。Java 开发人员有另一个理论优势：他们可以在没有数据库支持的情况下，更容易地运行应用程序。没有数据库支持就测 试 Rails 应用程序几乎没有意义，因为许多 Rails 值是通过元编程（metaprogramming）把 SQL 特性编织起来而得到的。所以，Java 测 试套件通常运行得更快，因为套件中的测 试用例不需要访问数据库。
如果使用 Java 代码生成，Rails 可以为您提供一些关于如何使用测 试生成增强您的代码生成的好主意。如果正在补充自己的测 试框架，那么 Rails 的测 试 API 既简单又漂亮。如果对超越 Java 编程语言感兴趣，那么 Rails 可以为轻量级的、数据库支持的应用程序提供一些真正的价值。
在这个系列的下一篇文章中，我将不再介绍 Rails，而是查看基于 Web 的建模策略。您将看到如何将代码生成用于动态语言。
- 默认 Web 页面实现，显示路线（trail）列表（叫做
-
在 Ruby on Rails 中进行单元测试第一部分（转发）
2010-07-14 15:00:29
转发，原地址：http://soft.zdnet.com.cn/software_zone/2007/0901/482329.shtml
在这一篇和下一篇文章中，将全面理解在 Ruby on Rails 集成开发框架中的测 试方式。第 1 部分侧重于测 试模型对象，并提供一些从 Rails 获得启发的策略，可以用这些策略使 Java 单 元测试更有效。第 2 部分把更多时间花在功能测 试和集成测试上。作为 Java 程序员，您对一些概念可能比较熟悉，特别是在测 试的时候，而其他一些概念可以拓展您的理解。
在这个系列的 前一期 中，了解了动态类型化会带来某些 bug 种类，静态类型化语言将在编译时捕捉到这些 bug。清单 1 的 Ruby 代码片段包含四个不同的 bug，这四个 bug 在运行时之前都不会显露出来：
清单 1. 带 bug 的 Ruby 代码
position = "2" #string, where a number was intended
position = positoin + 4 #position is misspelled, evaluates to 0
puts "The position is:" +
position.to_string #The method should be to_s
如果编译器能够捕捉 bug，那么这类 bug 解决起来是小菜一碟，但是如果依赖解释器，那么管理这些 bug 就困难得多。为了处理这些微妙的错误，动态语言的用户长期以来一直依赖于自动测 试。在进行测试的时候，比起其他语言，动态语言及其集成环境在一般意义和特殊意义上都具有显著的优势：
- 语言更简洁。测
试基本上是脚本编程，许多最好的脚本语言都是动态类型化的。
- 集成环境支持的假设可以让集成测
试更容易，也可能更强大。在 Rails 环境中将看到一些示例。
- 动态语言允许使用更松散的耦合，使一些测 试格式更容易实现。
在了解动态语言开发人员为什么这么热衷于测 试之后，现在是构建一个需要一些真正测 试的实际应用程序的时候了。
为了进展得快些，我采用了一个保存山地摩托车路线数据库的 Rails 应用程序。我将模型的几个测 试放在一起。如果想和我一起编写代码，那么所有需要的工具就是一个数据库引擎（我使用的是 MySQL）和 Ruby on Rails 1.1 或更新版本（请参阅 参考资料）。第一步是创建 Rails 项目。在命令提示符下输入
rails trails命令，清单 2 显示了命令和结果：
清单 2. 构建 Rails 应用程序
> rails trails
create
create app/controllers
create app/helpers
create app/models
create app/views/layouts
...partial results deleted...
create test/fixtures
create test/functional
create test/integration
create test/mocks/development
create test/mocks/test
create test/unit
create test/test_helper.rb
...partial results deleted...
create config/environment.rb
create config/environments/production.rb
create config/environments/development.rb
create config/environments/test.rb
...partial results deleted...
create log/server.log
create log/production.log
create log/development.log
create 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
end
end
def self.down
drop_table :trails
end
end
您需要创建和配置两个数据库：
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: localhost
test:
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 已经为您创建了测 试用例。框架不仅为这个简单的小程序生成了视图和控制器，而且还生成了有助于测 试用户界面的功能性测 试。
现在是运行一些测 试的时候了。请看第一个测 试，它已经在 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
end
end
确实，这个测试用例算不了什么，但您可以从中看出如何构架测 试代码，而且自己的测 试用例的模板也已经就位。请运行测 试，如清单 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
Java mock 对象
在解决测试数据库支持代码的困扰时，Java 开发人员经常使用 mock 对象而不是实际的数据库代码。Mock 对象设置起来比较难，通常难于理解，而且对于在数据库环境中工作的代码，也无法提供良好的理解。Ruby on Rails 支持不同的方式。
有三个问题影响了对数据库支持代码的测 试。它们都与两个特性有关：性能和重复性。与内存中的操作相比较，数据库调用的性能是非常低的。如果测 试运行需要太长时间，那么您可能就不想运行它们了。另一个问题是一个测 试用例对另一个测 试用例的影响。因为数据库调用在性质上是持续的，所以要把一个测 试在数据库中的变化与另一个数据库中的隔离开。最后的问题是前两个问题的组合。为了让数据库测 试用例可重复而增加设置和拆卸的负担时（为每个新的测 试用例添加记录、运行测 试并删除这些记录），带来的开销可能是让人无法接受的。与这种开销相比，测 试用例开销简直是小巫见大巫。
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 平台上进行测 试的方式。具体地说，使用这些想法中的一项或多项可以对测 试产生显著而直接的影响：
- 可以把测试用例的生成添加到任何现有代码生成当中。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 的类似策略（请参阅 参考资料）。
- 语言更简洁。测
试基本上是脚本编程，许多最好的脚本语言都是动态类型化的。
-
selenium还没解决的问题
2010-06-08 10:21:21
-
selenium 小结（一）
2010-06-07 17:06:33
最近一直在用seleniumIDE做测试用例，碰到了很多问题，但由于一直混乱，所以一直没时间没心情来总结一下
现在终于有点感觉了，觉得自己努力就可以做出来了。趁着今天刚刚完成一部分，来总结一下的。
1、如果打开新页面后输入信息时提醒找不到elements，则可以先用focus命令选中要输入的文本框
2、打开popup后如何关闭的问题：先用selectPopUp来选中，再用Close命令来关闭，光标就可以回到原本的页面了
3、若打开新页面后找不到elements，则可能是因为页面没有完全打开，所以找不到，这时把前边的Click改为clickAndWait
4、如果页面中有通过文本框输入来自动选择下面内容的（例如你输入邮编，则下面的城市、国家自动选择），在输入邮编后，要点击一下页面下面的选项才会填充进来，但click命令需要表明组件位置，此时可用type下面的文本框来等待，但输入的值要为空，而且之后要再重新给该文本框输入正确的值。以下为截取的command
type
PageContainer_InterContainerConsultantRegInfo_ConsultantRegInfo_InterContainerRegCustomerInfoMail_RegCustomerInfoMail_txt_Zip 77040
type PageContainer_InterContainerConsultantRegInfo_ConsultantRegInfo_InterContainerRegCustomerInfoMail_RegCustomerInfoMail_txt_HomePhone
type
PageContainer_InterContainerConsultantRegInfo_ConsultantRegInfo_InterContainerRegCustomerInfoMail_RegCustomerInfoMail_txt_HomePhone
1452365478
5、在录制时，用快捷键进行的操作很可能会录制不上，例如登陆，按Enter则不会录制上本该有的Click命令，要用鼠标点击
6、在同一页面上要输入两个地址或联系人等之类的时，如果有The same as的选项，选上之后要验证两边是否完全一样，则可以把其中原始的值保存下来（storeValue），再用waitForValue()来验证输入值是否和原始的一样
暂时想到的就这么多，想到了再继续写的。
-
QTP和LR的区别
2010-05-13 17:05:36
-
Analysis图
2010-04-28 13:56:36
-
关于web page breakdown
2010-04-27 10:07:01
-
精通与实战1
2010-04-23 15:19:05
-
LoadRunner学习小总结+小计划
2010-04-23 13:01:34
-
Web Page Breakdown
2010-04-20 13:33:26
-
Error 27492
2010-04-16 15:34:58
-
Error 27727-27728解决方法
2010-04-16 14:33:35
-
LoadRunner自带实例安装问题（补充）
2010-04-15 15:17:23
-
LoadRunner自带实例安装问题
2010-04-15 13:14:59
-
软件测试人员容易遗漏的测试缺陷(转发)
2010-04-01 13:25:02
标题搜索
我的存档
数据统计
- 访问量: 29729
- 日志数: 95
- 建立时间: 2008-11-05
- 更新时间: 2013-09-17
