Web开发敏捷之道（第二版）

Web开发敏捷之道（第二版）

《Web开发敏捷之道（第二版）－应用Rails进行敏捷Web开发》这本书的中文版已经上市，关于这本书在RoR书籍市场的地位就不用赘述了。有意思的是，这本经典的Ruby on rails教科书和我们JavaEye网站非常有缘分：

去年8月份，这本书第一版中文版上市的时候，正值我们使用Ruby on rails开发JavaEye2.0的关键时期，所以我毫不犹豫购买了三本，开发团队人手一册，那个时候，我们开发团队也是刚刚开始学习Ruby on rails，所以的确帮了不少忙。今年8月份，这本书第二版中文版也上市了，刚巧我们开发团队正在开发JavaEye3.0，这次是完全抛弃掉了JavaEye2.0的代码，彻底重写整个网站的代码，对代码质量提出了很高的要求，所以也要求我们对Ruby on rails有很好的掌握，不出意外，这次还是人手一册。

这本书的第一版主要是针对rails1.0版本的，第二版是针对rails1.2版本而写，所以新的内容很多，有意思的是，我们JavaEye2.0和JavaEye3.0的代码变迁也挺符合这本书两个版本之间的内容变动，第二版主要添加的内容有：

一、数据迁移

数据迁移功能是rails1.1版本引入的，非常受程序员的欢迎，去年我们开发JavaEye2.0的时候，rails1.1其实早就发布了，但当时第一版没有这部分内容，我们也不清楚这个功能。所以数据库的维护都是直接通过数据库工具来修改表结构，但这也造成了一些问题：例如开发环境添加了字段，但是生产环境忘记修改数据库，造成代码发布以后，网站频频报错的问题出现了好多次。

这次我们开发JavaEye3.0，就是完全使用数据迁移功能来维护数据库，可以杜绝问题的再次发生了，当然数据库的版本跟踪也方便了很多。

二、REST支持

REST是rails1.2引入的功能，也是rails框架未来的核心功能，这次我们开发JavaEye3.0，就是按照REST的架构风格来设计和开发的。但是第二版的REST功能介绍显得比较简略，不够详细，如果你的rails项目打算完全基于REST，那么可以参考一下beast开源项目，实际上我们就是大量参考了beast的代码写法。

三、模型对象的多态关联

多态关联是ORM很有用处而且很有趣的一项功能，第二版详细介绍了rails的多态关联功能，例如JavaEye3.0当中，我们就使用多态关联特性来实现帖子、博客、站内短信都可以带有附件这样的功能，也使用多态关联特性实现帖子、博客、评论都可以打tag这样的功能。

四、assert_select和集成测试

我个人觉得assert_select是一项很伟大的功能。我们整天都说TDD、TDD……，但是web应用，你怎么TDD？测试能够覆盖到页面上去吗？这在其他web开发当中是一个难题，但是assert_select就可以，而且完成的很漂亮，很简单。事实上，有了assert_select和集成测试，类似selenium之类的外部测试框架完全可以退休了。

五、其他的一些新内容

例如第二版里面增加了RJS和render :update功能，在JavaEye2.0里面，很多AJAX功能我们也是直接写prototype JS库的调用，现在基本上都改成了render :update了；
第二版里面增加了发送HTML格式和带附件的email功能，这个也是我们目前很迫切需要的功能；
第二版里面增加了使用mongrel群集部署rails应用的内容，这部分内容恐怕是我们JavaEye3.0唯一不会采用的新内容。

应该说是让Selenium回到它原本的位置：验收测试
过去两三年，我看到很多项目用Selenium做界面级的TDD。这是不好的，虽然可能是没有办法的办法。Rails的功能测试/集成测试和Selenium组合起来，能够创造出更好的测试策略。

7月20号在王府井书店买了一本《Web开发敏捷之道（第二版）》和《programming ruby （第二版）》。《Web开发敏捷之道（第二版）》不错，只是翻译得让我这个英语不是很好的人都发现了好几处错误（还未看完），不过总比看E文好，以前都是挂起金山词霸看英文版，东拼西凑在单位局域网中搞了个企业网站。现在不用费力了，用母语始终比外文好理解。

这个不同意，因为Rails也是自己有一个html解析器。
我就遇到过，一个页面的js特别复杂，而且包含了更复杂的js,
尤其是动态生成js的时候。
rails 的 assert_select 就会提示错误。

关键是测不到真实的效果
比如说，用户点一个按钮，下拉出一个框，再点框里的一个链接，显示更多的信息，这都是AJAX的效果
如果只是用Rails的功能测试，你只能测是否有最初的那个按钮存在
点了按钮之后是否有框框出现，框框里的东西能不能点，点了有什么效果
这些都是测不到的

这种UI功能测试应该用人工来测，最好配备专职测试人员。这样的测试不是非得是程序员才能完成

验收测试就不该自动化吗？
只有程序员的工作才应该自动化吗？

测试这东西人做肯定没有机器做的好，谁愿意在你每次提交代码的时候反复的点击和输入同样的东西测试前不久才测过的东西。而且只要是人做，肯定会由出错的时候，机器做出错的几率是很小的，出错也是程序的错，测试自动化还可以减少一些测试人员

Selenium 完全可以实现。
而且这样的工具多得是。

偶们有专职测试团队，05年的时候，他们还是用人工测试的
后来出了几件事故，原因都是一样的：上了某个版本的新功能，导致一些旧功能出现bug，而这些bug如果有自动化验收测试支持的话，就不会成为漏网之鱼了。
痛定思痛，最后决定用自动化工具，06年的时候，对比了Sahi，Selenium以及Watir，最终选定了Sahi。
对于没有编程基础的测试人员来说，要用好这些工具，必须得学习一定的编程基础，对于测试人员的要求也更高。
但是这些投入绝对比找几十个廉价的暑期实习生MM来人工一个个点击要更有效，更有保障。