引子
公司在新项目上 BDD 的开发模式，迄今已经差不多 2 个月了。
按最初的分工，开发写 rspec， 测试写 cucumber，双线并行。
加上最新配置好的 jenkins ci 环境，整个开发流程走的很顺，
代码质量也得到了很好的控制。
今天按老样子写某个 component 的新加的feature的场景，
写 step definition 的时候，发现 stepdef.rb 文件已经
300 多行了。 瞬间有种再不控制就爆炸的感觉。
于是就把问题抛了出去：
cucumber 的 step definition 爆了。。。 越写越多，真难控制！
讨论
我将问题抛在了 TestCirle 的群里，讨论地断断续续从下午一点到下午六点。我将每个人的发言总结下。
MIC-Seeyon
step_definition 之上抽象一些 common function，再之上是 page object 的应用。
这样基本就封装了大部分逻辑了。这样就算 step_definition 再有多，也不会有多少代码吧～如果有页面很多 ajax 操作，你可以把 ajax 的基础页写成 basePage，
然后其他的 ajax 业务写成不同的 page，继承 basePage 即可～如果觉得实现太重的话，可以分工程，通用的抽取出来，其他的不同模块或者业务，基于这部分 common 的，搞自己的 feature，自己实现～
这样对具体的编码的人来说就轻了～把握好 feature 的度, 整理一下测试用例的执行场景哦～
step definition 里面有太多冗余的东西的话就会很重，需要去冗。
如果有的话，那也得做一层基本的网页操作的抽象～
我是说业务和交互级别的 actions
比如根据 label 操作 input
各种条目的选择，操作，内容获取
这些可能都跟你产品的前段设计有关哦～我们是这么做的：
- webdriver 的 api 操作封装一层
- 然后产品使用的前段控件封装一层
- 然后业务级别的逻辑跟操作封装一层
- 然后常用的操作组合封装一个层
- 最后才是 step definition
cucumber就是一个驱动自动化测试的粘合剂
横刀天笑
逻辑肯定是在 page object 里的, page object 应该暴露业务接口，既然暴露业务接口，那肯定是包含业务逻辑的
比如我们酒店首页 HotelHomePage。有个搜索功能，那 肯定提供一个 search 的方法，search 里接受一个查询条件page object，应该从用户角度来看，你这个页面提供了哪些功能,从业务功能上来看 po，而不是从操作上, 然后 step defs 里是流程的描述
持续交付里有一章讲自动化测试, 里面讲了一个三层:
- 测试描述层(case)
- 测试实现层，或者叫流程层
- 应用接口层(比如使用 selenium 或 httpclient 之类的和应用程序打交道)
插曲 -_-!
如何做一个能害死人的自动化测试工具
http://www.ltesting.net/ceshi/ceshijishu/zdcs/2013/0806/206547.html?1375845711
思考
我回想了下，这个项目一开始没采用 page object， 因为：
- 以为项目不复杂，参考另一个公司 rails 项目的 cucumber features。
- 使用了 pickle，导致 feature 撰写的时候， 有过多的 code 色彩，如果使用 page object 的话 就有点混搭的感觉，不伦不类了。
- 最早之前用 page object 有些厌倦了。 特别 ajax render 的页面，导致继承 base 的页面过多。
关于第一点：
接触过很多 rails 的项目， 往往是将 cucumber features 作为 High level 的 acceptance test， 挑选的场景的粒度都是比较粗。
而且 rails 项目的 cucumber 基本都是开发来写的，我一开始就把自己定位为开发。
关于第二点：
pickle 非常强大
Pickle gives you cucumber steps that create your models easily from
factory-girl, machinist, or fabrication. You can also just use ActiveRecord as a factory but it’s not as cool.
但是使用 pickle 的前提是你必须了解 model， 了解各种 model 的 factory， 也就是其实你已经
是从开发的角度来考虑如何测试代码了。 你在 steps 里面的数据设计，其实都是你知道的结果，并不是测试出来的。
pickle 的使用，使 Given, When 和 And 对 测试和 stakeholder 不太友好。 这不像 page object 的风格。
关于第三点
我在前面一个项目中应用了 Page Object， 我在博客里也粗略地介绍过， 参考 webdriver
由于我们项目大量使用 ajax， 导致基于 basePage 的子页面各种各样的特别多。个人感觉也不太舒服。
综上，所以一开始就忽略了 page object。
目前
我们现在仅仅把 features 进行了分类（利用目录结构），将所有的 step definition 都放在了一个 rb 文件里。随着以后的不同的场景，失控也是时间问题。
结论
目前看来， 这个项目的 cucumber 想要完成的是 整个 UI 的自动化测试。 要去冗，去重需要做的是：
- 合并和参数化
- Page Object