使用Cucumber的15个建议

1、特性（Feature）文件应该描述特性，而不是应用程序的组成部分

　　每个特性文件应有一个好的命名，并保持特性的专注

 

2、避免特性与领域逻辑的不一致性

　　使用Cucumber的一个好处是可以让客户参与其中。为此，在编写你的故事（Story）时，应确保使用客户的领域语言。这一活动的最佳做法是让客户也参与编写故事。

 

3、用组织代码的思想来组织你的特性与场景（Scenary）

　　组织特性的一种有效办法是按照它们运行的速度。可以使用2-3级的粒度来表示：

     　　Fast：场景的运行非常快，例如十分之一秒；

     　　Slow：运行速度慢，但还不至于到难以忍受的地步，可能每个场景耗时1秒；

     　　Glacial：耗时很长的场景；

　　你可以采用多种方式来分解（以及适量的合并）

　　　　1）将它们放到各自的特性中；

　　　　2）将它们放到各自的子文件夹下；

　　　　3）给它们打标签（tag）

 

4、使用标签（tag）

　　标签能够以非功能的方式很好地组织你的特性与场景。你可以使用@small、@medium、@large或者@hare、@tortoise与@sloth。使用标签可以保持在结构上将特性的场景组织在一起，却可以分开运行。标签也有助于特性/场景在组之间的移动，甚至将特性的场景放到不同的组中。

　　采用标签的方式组织特性/场景，好处在于能够在不同时刻，或不同频率有选择地运行。例如，运行快速的特性可以经常运行，大而慢的场景就可以根据一定的日程安排来运行。

　　标签不仅可以将不同的场景放在不同的组，还可以根据场景运行的速度：

     　　根据运行的时间：@checkin、@hourly、@daily

     　　根据外部依赖：@local、@database、@network

     　　层次：@functional、@system、@smoke

     　　其他

 

5、使用Rake任务来运行特性

　　这种方式可以为特性的运行提供一致的环境：每次运行都使用相同的设置与参数。另一个好处是它能够很好地与持续集成工具配合。因为只有一个单一的点进入Spec，所有的选项与参数都被封装起来了。

 

6、不要过度使用Background（坚持使用Given）

　　Background越大，理解每个场景就越困难。包含所有细节的场景是自包含的，它可以提供可读性。

 

7、使特性更独立，能够自我决断

　　场景之间不应有任何耦合。耦合的源头来自于遗留在场景之间的状态。这样的设计会带来偶然性的错误，例如，一个场景会添加一条记录到数据库，随后的场景依赖于存在的该条记录。这样的特性可能会工作，然而一旦改变场景运行的顺序或者并行运行，就可能带来问题。场景必须完全独立。

　　每次运行一个场景，就应该得到相同的唯一的结果。场景的目的是描述系统的工作方式。如果你对该场景没有足够的信心，那就不要编写该场景。如果已经存在一个无法自我决断的场景，那就找出来，修改它。

 

8、要为“非乐观路径（Non-Happy-Path）”用例编写场景

　　乐观路径的测试很容易；边缘用例与失败场景需要耗费更多的精力与努力。

 

9、遵循DRY：重构和重用Step Definition

　　仔细查看是否存在那些与特定的特性无关的Step Definition可以重用。随着项目的进展，应该收集Step Definition的库。理想状态下，最终的Step Definition可以跨项目重用。

 

10、在Step Definition中使用库（例如Chronic）来解析时间

　　它允许你在场景中能够很自然地使用时间。对于相对时间而言非常有用。

　　　　Background: Given a user signs up for a 30 day account

　　　　Scenario: access before expiry When they login in 29 days Then they will be let in

　　　　Scenario: access after expiry When they login in 31 days Then they will be asked to renew

 

11、重新阅读以及重构和改善场景与步骤（Step）的编写

　　一有机会就要对步骤进行泛化与重用。我们应该收集步骤的可重用库，使得我们在编写额外的特性时可以更省事儿。

 

12、重构语言与步骤使其更好地反映领域

　　这是前一点的扩展；随着你对领域以及客户的语言和术语的理解，可以及时更新用在场景中的语言。

 

13、使用复合步骤来强化你的语言

　　复合步骤可以让特性变得更简洁。例如：

　　Given /^the user (.*) exists$/ do|name|

　　　　# ...

　　end

　　Given /^I log in as (.*)$/ do|name|

　　　　# ...

　　end

　修改为：

　　Given /^(.*) is logged in$/ do|name|

　　　　Given "the user #{name} exists"

　　　　Given "I log in as #{name}"

　　end

 

14、使用并行的Step Definition来支持特性的不同实现

　　例如，使用Webrat和Selenium来运行特性。将这些Step Definition放到不能自动加载的地方，然后通过命令行或者rake任务去require。

 

15、避免使用联合步骤

　　每一步只做一件事情，不应该在一步中使用“and”，例如：

　　Given A and B

　　应该分解为：

　　Given A And B

 

 

 

 

转自：http://www.agiledon.com/?tag=cucumber

英文出处：http://www.engineyard.com/blog/2009/15-expert-tips-for-using-cucumber/