Rails每周闲碎(十): Tools

1. will_paginate

 

   will_paginate 是一个非常简单易用的rails插件，它提供了“分页”的查询功能和一些页面模板。

 

   在查询功能上，这个插件的本质是在rails模型对象的查询方法上增加了一些条件。比如paginate方法可以看成是find方法的基础上增加了:page和:per_page两个参数，来告诉查询页数和每页的记录数量。

 

   组装成的sql语句大概如下：

 

SELECT TOP 50 FROM (SELECT ROW_NUMBER() OVER ( ORDER BY id ) AS row_num) AS t 
WHERE row_num > 1000

#SQL Server版本
#其中的50是:per_page, 1000是由:page计算而得。

 

   而在页面方面，will_paginate也提供了一些模板和view的helper方法，使页面的实现非常简单：

 

 

<%= will_paginate @posts %>

 

2. ActionMailer

 

    ActionMailer 让你通过一个model和view就能建立起email。

 

    需要注意的几点：

 

    a. 在view中的url：用url_for等方法生成url，需要指定host。Mailer的view跟一般的view不同，不是通过请求生成的，所以无法从request中获取host。

 

    b. content_type：我们可以指定邮件的content type，如果没有指定，则其由view的文件名决定。比如signup_notification.text.html.erb说明邮件的content type是“text/html”。

 

    c. smtp server： smtp配置的设定，ActionMailer::Base. smtp_settings。

 

 

 

3. rake task: environment

 

   Rake task是独立于环境而执行的，除非这个task有个前置task是：environment。

 

task :load_data => :environment do
   include DataLoader
   load_data
end 

 

    在上面这个例子中，我们需要include DataLoader这个module（定义在lib目录下），并调用它的load_data方法。如果没有environment这个前置task，那 么include就会失败，因为当load_data task执行时，并没有应用环境，那么就不会知道load path等。

 

 

 

4. jmeter

 

    jmeter可以设置代理，让浏览器的请求都通过jmeter，以此来录制浏览器的request。结合selenium，简直完美。

 

评论

2 楼 andyhu1007 2009-07-19  

liuming 写道

我对Cucumber的看法是，它正是尝试在业务和技术之间找到一个平衡点，或者说是折中方案。

我们最近也上了Cucumber尝试把业务、测试和开发融合起来，也正在探索Cucumber的做法到底是两边讨好还是不伦不类。目前我的接到的信息是，业务人员还是比较接受Cucumber。反而开发人员有时还会像您说的那样，由于Cucumber维护起来需要费些神，还会懒一些。有限制是肯定的，但起码业务人员和技术人员双方做一些努力向对方靠近一些的话，我们就会省了一个中间人或者中间步骤，把长篇大论的自然语言需求翻译成逻辑。另一方面是类似于Cucumber这类BDD方案可以引导开发从外到内的进行，也就是说从客户（或者说业务）的角度去看一个系统，这样我们就省了很多工作去假设和处理一些可能十年也不会遇到的逻辑。

还有一个方面是不知道楼主有没有用其它的辅助工具来帮助完成Cucumber的动作执行？我们在应用中所用的Watir组件能够实际地调用浏览器来执行测试。测试人员虽然在写测试是头痛，但写好之后也挺爽的，每次都看着它动就行了。

我们用的是selenium。

你说的有道理。我们项目中之所以客户或者业务人员不会看cucumber用例，主要原因是客户验收条款的管理是在mingle上面。而cucumber和验收条款之间并没有同步，还是要靠业务人员和开发人员之间的沟通。

要有效利用cucumber，必须得将客户验收条款和测试用例紧密结合起来。最理想的情况是能做的：

1. 由客户或者业务人员写就定义成cucumber的测试用例样式的客户验收条款。

2. 由开发人员或者测试人员实现这些测试。

3. 实现客户验收条款和测试用例的同步。

这样，客户改动的就是测试用例；而客户验收条款一改，测试就会警报。

但本质上，这个东西我觉得还是挺复杂的。它实质上还是编程语言，并没有让业务人员或者客户可以脱离开发人员进行独立操作的可能性。既然如此，不如让客户或者业务人员学习一下method chain怎么写，不是差不多么。

1 楼 liuming 2009-07-19  

我对Cucumber的看法是，它正是尝试在业务和技术之间找到一个平衡点，或者说是折中方案。

我们最近也上了Cucumber尝试把业务、测试和开发融合起来，也正在探索Cucumber的做法到底是两边讨好还是不伦不类。目前我的接到的信息是，业务人员还是比较接受Cucumber。反而开发人员有时还会像您说的那样，由于Cucumber维护起来需要费些神，还会懒一些。有限制是肯定的，但起码业务人员和技术人员双方做一些努力向对方靠近一些的话，我们就会省了一个中间人或者中间步骤，把长篇大论的自然语言需求翻译成逻辑。另一方面是类似于Cucumber这类BDD方案可以引导开发从外到内的进行，也就是说从客户（或者说业务）的角度去看一个系统，这样我们就省了很多工作去假设和处理一些可能十年也不会遇到的逻辑。

还有一个方面是不知道楼主有没有用其它的辅助工具来帮助完成Cucumber的动作执行？我们在应用中所用的Watir组件能够实际地调用浏览器来执行测试。测试人员虽然在写测试是头痛，但写好之后也挺爽的，每次都看着它动就行了。