cucumber - mindpin/docs GitHub Wiki
Cucumber 经验总结
https://ruby-china.org/topics/7119
宋亮：按我个人的理解，cucumber 非常适合用来衔接业务分析和 demo.
在 demo 开发时，用 cucumber 做测试驱动开发，会显得比较自然。
我会首先尝试在 KC 题库 + 考试模块的开发中使用这一工具手段。设想的使用过程：
吴笛 / 夏实来写 behaviour text ..
宋亮 / 李飞配合编写 step definition ..
开发 demo ..
入门介绍
https://danielzhangqinglong.github.io/2015/03/02/rails-test-samples/
开发时可以安装 sublime text 2 插件
使用 ctrl + shift + p 选 install 输入 cucumber 就可以找到
一张不错的图
中文关键词对应表
| keywords | 关键词 |
|---|---|
| feature | "功能" |
| background | "背景" |
| scenario | "场景", "剧本" |
| scenario_outline | "场景大纲", "剧本大纲" |
| examples | "例子" |
| given | "* ", "假如", "假设", "假定" |
| when | "* ", "当" |
| then | "* ", "那么" |
| and | "* ", "而且", "并且", "同时" |
| but | "* ", "但是" |
| given (code) | "假如", "假设", "假定" |
| when (code) | "当" |
| then (code) | "那么" |
| and (code) | "而且", "并且", "同时" |
| but (code) | "但是" |
宋亮的一些 tips 和笔记
- 在很多场景下可以用 * 替代部分关键词
- 每个场景都应该是独立的，不要依赖其他场景来运行
- 要避免把 Then 那么 部分的描述放到场景名称里
- 例子不要太多，要精心选取核心实例
https://github.com/josephwilk/pairwise/wiki - 场景描述要避免过分细节化，具体参考黄瓜书第六章
通过嵌套步骤实现 feature 复用的方法见 81 页. 但是应该尽量避免这宗嵌套步骤的写法。 - 避免使用 imperative programming （命令式），而是使用 declarative programming （声明式）
前者就像 ruby，后者就像 css. 要指明 what 而不是指明 how.
参考黄瓜书 94 页 - relishapp.com
这个网站非常棒！可以以更加容易阅读的形式展示和管理所有 feature - 可以用
cucumber --dry-run来仅解析测试结构，而不实际运行测试 - 要优先去考虑 happy path ，参考 129 页
- 从解耦角度考虑 cucumber 应该是直接针对领域模型，而和用户界面保持彼此无关的。
http://i.teamkn.com/i/mHr7KMMQ.png - 标签机制配合 before after around 会特别方便，参考 144 页
- 有时候需要一些技巧来处理异步系统调用的问题，参考 154 页
- 测试分为规格测试和特性描述测试，规格测试也就是一般意义上说的那些测试。
而特性描述测试适合于用来探索其他人开发的业务系统或老旧代码。是用来覆盖系统行为，而不是提前驱动开发的。
运用一些技巧，可以使得 cucumber 在维护旧系统方面也起到很好的作用。
在某些要进行 bugfix 的情况下，也可以使用测试去覆盖。 - 可以考虑让所有业务在不依赖 javascript 的方式下运作起来。这样能非常快的进行测试。
也就是说，先实现一个纯 HTTP 版本的应用.
而且，在这个基础上，添加 javascript 是简单整洁且愉快的。
