使用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/

 


本文转自贺满博客园博客,原文链接:http://www.cnblogs.com/puresoul/archive/2012/03/01/2375839.html,如需转载请自行联系原作者。

目录
相关文章
|
6月前
|
消息中间件 测试技术 Linux
GoogleTest 测试框架
GoogleTest 测试框架
|
XML Ubuntu 测试技术
【GoogleTest】GoogleTest单元测试(1)快速上手
【GoogleTest】GoogleTest单元测试(1)快速上手
|
测试技术 Python
|
Ruby
《Cucumber:行为驱动开发指南》——1.4 Cucumber如何工作
Cucumber是一个命令行工具。运行时它会从普通语言编写的称为特性(feature)的文本文件中读取你的规格说明,解析需要测试的场景(scenario),然后针对你的系统运行这些场景以达到测试的目的。
2161 0