zoukankan      html  css  js  c++  java
  • 使用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/

  • 相关阅读:
    单例模式
    设计模式
    C#判断Textbox是否为数字
    C#判断输入的是否是汉字
    C#如何测试代码运行时间
    网上 server2008数据库恢复方法
    C# 控件的缩写
    SQLite主键自增代码
    Sqlite数据库联合查询及表复制等详述
    C#中超链接方法
  • 原文地址:https://www.cnblogs.com/puresoul/p/2375839.html
Copyright © 2011-2022 走看看