【Cucumber】【命令行】

知识点 参考：https://www.cnblogs.com/worklog/p/5253297.html

1. cucumber的命令行选项

首先查看命令行选项。和其它命令行工具一样，cucumber提供了—help选项。下面是cucumber帮助的一个缩减版本：

$ cucumber --help

-r, --require LIBRARY|DIR Require files before executing the features.

      --i18n LANG   List keywords for in a particular language.Run with "--i18n help" to  see all languages.

-f, --format FORMAT How to format features (Default: pretty).

-o, --out [FILE|DIR] Write output to a file/directory instead of STDOUT.

-t, --tags TAG_EXPRESSION Only execute the features or scenarios with tags matching TAG_EXPRESSION.

-n, --name NAME Only execute the feature elements which match part of the given name.

-e, --exclude PATTERN Don't run feature files or require ruby files matching PATTERN

-p, --profile PROFILE Pull command line arguments from cucumber.yml.

-P, --no-profile Disables all profile loading to avoid using the 'default' profile.

-c, --[no-]color Whether or not to use ANSI color in the output.

-d, --dry-run Invokes formatters without executing the steps.

-a, --autoformat DIR Reformats (pretty prints) feature files and writes them to DIR.

-m, --no-multiline Don't print multiline strings and tables under steps.

-s, --no-source Don't print the file and line of the step definition with the steps.

-i, --no-snippets Don't print snippets for pending steps.

-q, --quiet Alias for --no-snippets --no-source.

-b, --backtrace -S, --strict Fail if there are any undefined or pending steps.

-w, --wip Fail if there are any passing scenarios.

-v, --verbose Show the files and features loaded.

-g, --guess Guess best match for Ambiguous steps.

-l, --lines LINES Run given line numbers. Equivalent to FILE:LINE syntax

-x, --expand Expand Scenario Outline Tables in output.

  --drb         Run features against a DRb server. (i.e. with the spork gem)

  --port PORT      Specify DRb port.Ignored without --drb

  --version      Show version.

-h, --help You're looking at it.

1. 运行一部分场景

当场景和feature逐渐增长时，我们会经常运行仅仅一个（或多个）场景，这样会更快的反馈。当我们在一个新场景中工作时很有用。让我们看看如何这样工作：

使用Tag表达式过滤

使用tag选择最简单的方法是给它一个单独的tag，例如：这个命令会让cucumber运行使用@focus标志的场景

$ cucumber –tags @focus 需要运行有@focus和@email标志的所有场景

$ cucumber –tags @focus,@email

应用逻辑AND来表明我们想要运行由@fast并且由@focus或者@email标志的场景：

$ cucumber –tags @fast –tags @focus,@email

这里我们使用—tags两次。这两个会使用AND逻辑连在一起。 少数场景标志@slow是更有意义的。如果想要运行所有没有标志@slow的场景，使用波浪符号：

$ cucumber –gets ~@slow –tags @focus,@email

下面介绍运行一部分场景的另一种方法。

在line上过滤 Cucumber提供一个方便的方法指定你要运行的场景的行号。例如：

$ cucumber features/something.feature –line 45

如果文件超过一个场景，它就仅仅运行在45行的那个场景。

你可能注意到cucumber打印feature的位置和行号。

features/something.feature:45

如果要重新运行，可以使用如下命令：

$cucumber features/something.feature:45

这个命令和使用—line参数效果相同。冒号允许你指定多个行号，允许你指定多个场景来运行：

$ cucumber features/something.feature:45:89:107

如果你喜欢，你也可以使用—lines参数来实现这个功能。Cucumber不关心你使用line还是lines。

使用名称过滤

如果tag和line过滤都不能满足你的要求，你可以使用名称来过滤。例如，你要运行名称中包含logout的场景，这些场景分布在多个feature文件中，并且没有一个特殊的tag来指定他们。使用下面的方法运行他们：

$ cucumber –name logout

你也可以使用—exclude指定一个名称来排除场景。

1. 改变cucumber的输出

Cucumber的默认行为是输出和Gherkin源文件类似的结果—附带一些颜色、step定义位置和参数高亮的信息。这并不是输出结果仅有的方式。Cucumber允许你使用一个不同的输出格式。例如：你可以使用最小的报告，每个step只包含一个字符，就是progress格式：

$ cucumber --format progress

..U--..F..

每个字符表示每个step的状态：

l .意味着通过

l U意味着未定义

l -意味着忽略

l F意味着失败

Cucumber也有一些内置的格式：html，json和junit。当你在一个持续集成环境中运行cucumber时，junit是很方便的，因为大多数持续集成服务器知道如何解释JUnit报告。下面更详细。

特殊的格式器

Cucumber绑定了一些格式，可以创建输出，但这些输出并不真是用来作为运行报告的。这个格式更多是来帮助开发的。

Usage格式列出你的工程中所有的step定义，和使用step定义的step。它显示了没有使用的step定义，使用平均执行时间对step定义进行排序。Usage的输出可以很快找出缓慢的部分，也是一个对你的step定义全面把握的好方法。

Stepdefs格式和usage很想，信息有点减少。

最后还有一个rerun格式。这是一个特殊的格式：

$ cucumber -f rerun

如果所有的场景都通过，rerun格式不会输出任何信息。然而，如果有失败场景，它会输出他们的位置，你可以拷贝和粘贴输出来重新运行场景。当确认失败场景时，这个选项可以节省很多时间。

为文件指定格式和使用多个格式

通常，所有格式都会打印到输出窗口。因此，如果我们想要看通常的pretty输出，但是想要一个html或者rerun格式怎么办呢？使用—out选项即可。它告诉cucumber不要输出到控制台，输出到文件中。例如：

$ cucumber -f pretty -f html --out cukes.html -f rerun --out rerun.txt

这个命令告诉cucumber编写HTML报告到cukes.html中，编写rerun报告到rerun.txt文件中，最终显示pretty格式到控制台上。

显示完整回溯堆栈

使用—backtrace选项导致cucumber为每个失败打印完整的回溯调用。当你在查找bug时非常有用。

1. 指定step定义的位置

你有没有奇怪：cucumber如何找到你的step定义?cucumber只会在featues/step_definitions中期望找到他们。事实上，如果你重命名这两个目录为jolly/jumper，运行cucumber jolly，也能正常运行。

Cucumber递归地扫面一个目录的rb文件来加载，如果在他们里面有step定义，他们就会被加载。理解什么目录会被cucumber扫描是很重要的。一旦你理解了它，你就从疑惑中解放出来。演示一个例子，加入你这样管理你的feature和step定义：

features

├── billing

│ └── credit_card.feature

├── scoring

│ ├── multi_player.feature

│ └── single_player.feature

└── step_definitions

├── billing_steps.rb

└── scoring_steps.rb

如果你使用cucumber features或者cucumber来运行，一切都很正常。如果有一天你添加一个新场景到credit_card.feature来支持一个新credit卡。然后运行：

$ cucumber features/billing/credit_card.feature:104 -f progress

UUUU

所有的step都是未定义的，即使你的新场景都是重用的已存在的step定义。为step定义和支持代码扫描的目录是由feature文件决定的。如果你给了一个feature文件，它就会在它的目录下查找rb文件。如果你给它一个目录，它就会在那个目录下查找。你可以通过—verbose选项查看cucumber在哪里寻找代码。

解决这个问题的方案是使用—require来显式告诉cucumber到哪儿去加载代码。前一个例子正确的方式是：

$ cucumber features/billing/credit_card.feature:104 -f progress -r features

...F

我们的代码现在就能找到并且加载了，我们可以继续开发我们的新场景。你也可以通过一个自定义配置文件来实现它。

1. 在Progress中管理你的工作

你应该尽量避免存在大量的pending或者半成品的feature和场景。这会让我们很难保持注意力，它对每个feature的交付周期也有影响。对于开始启动但未完成的工作，有一个术语叫work in progress，简称为WIP。如果你的项目保持WIP的低数量，每个feature的周期时间也会更短。

Cucumber帮助你管理你的WIP，使用tag和—wip选项。尽量养成为每个场景的习惯，正在进行时标记@wip，通过时移除这个tag。如果你的项目组同意一直保持WIP少于3个。可以使用下列命令强制执行：

$ cucumber –wip @wip:3

这也有一些有趣的影响。首先如果cucumber发现超过3个@wip场景，它会立即失败，不会执行任何场景。这个标志说明这里有太多的场景正在工作中，一些场景需要通过（或者移除掉@wip），另一些才能添加进来。

另一个影响是：任何场景通过（记住，你仅仅运行@wip的场景），cucumber也会失败。这种失败提醒你移除@wip标志。

1. 使用profiles

当你对不同的命令行选项感兴趣后，试着使用更多的选项，在命令行中一遍又一遍地输入他们是很枯燥的。Cucumber允许你存储命令行选项，保存到一个cucumber.yml文件中。 这个文件必须放在你工程目录下或者在config目录下。下面是一个例子：

default: --tags ~@wip --require features

wip: --tags @wip:3 --wip --require features

现在，如果你运行cucumber –profile wip，关键字wip的命令行选项会自动附加到你的命令行中。如果你没有指定—profile，cucumber会使用default的选项。注意：我们添加了—require features到所有profile中。因为，我们想要让cucumber自动加载definitions和支持代码，不管我们想要运行哪个文件夹中的feature。

1. 从Rake中运行cucumber

很多项目使用构建工具来执行常用任务。对于ruby工程，Rake是实际上的构建工具。Cucumber有一个Rake任务，使得从rake中运行cucumber很容易。如果你使用cucumber-Rails，自动安装时，你就会有Rake任务。

如果你还没有使用Rake，自己安装很容易。在你的工程根目录下添加这个到Rakefile文件中。

require 'cucumber/rake/task'

Cucumber::Rake::Task.new # defines a task named cucumber

现在你可以从Rake中运行Cucumber：

$ rake cucumber

当你从Rake中运行cucumber时，cucumber.yml中的profile会自动执行，但是你可以在Rakefile中定义命令行选项：

Cucumber::Rake::Task.new('cucumber_progress') do |t|

t.cucumber_opts = %w{--format progress}

end

现在你知道从本地命令行和Rake中两种方式如何运行cucumber，你也可以使用你的持续集成环境来运行它。如果任何场景失败，Cucumber会有1作为状态码，因此你的持续集成服务可以正确检测失败。

1. 在CI（持续集成）中运行cucumber

很多项目组安装他们的CI来每次运行cucumber，互相共享改变。因此这是一个命令行工具，没有任何需要做的，仅仅需要把cucumber命令放入到CI工程的配置下就行了。

你可能想要为CI使用一些不同的命令行选项。你可以通过定义一个特殊的profile。

Being Strict

当我们开发一个新场景时，存在未实现的或者pending的step是很正常的。一些项目组尽力保存主线上没有这样的step。

CI系统通过检查进行的推出状态来检测失败。如果有一个或多个失败的step，默认cucumber仅仅存在一个失败状态。如果你在CI环境中运行Cucumber，如果有人添加了未实现的step或者pending的step，你可能想要它失败。

如果我们传人—strict选项，如果未实现的或者pending的step就会和failing一样，返回非0值。你可以在运行cucumber后检查返回值。

OS X or Linux

$ echo $?

Windows

$ echo %ERRORLEVEL%

共享报告

前面我们看到如何使用—format选项改变cucumber的输出。如果传入--out JUNIT_DIR --format junit到cucumber中，你可以配置CI服务器来从JUNIT_DIR中获取报告，然后分析。一些CI服务器可以生成趋势图，向你展示你的构建是如何变得健康的。这是一个很好的方法：检测你的项目是进化了还是倒退了。

你也可以使用--out HTML_FILE --format html来生成HTML报告。如果你有浏览器自动化工具，这就非常好用，因为你可以嵌入浏览器的截图到HTML报告中。