在 Cucumber 功能文件中使用变量？答案

【问题标题】：Using variables in Cucumber Feature files?在 Cucumber 功能文件中使用变量？
【发布时间】：2016-02-26 07:49:06
【问题描述】：

我的团队正在使用 Cucumber 测试 REST API。这些步骤调用 API，而场景有“假设我使用 JSON YYY 调用 XXX”之类的内容。

在功能文件的后台设置 JSON 变量，然后在不同的场景中操作/使用它们是不是非常糟糕的做法？我们的许多测试都使用相同的 JSON 对象，仅包含 1-3 个已编辑元素。我想为一个场景做这样的事情：

Given I update J element to K value in JSON YYY As <NewJsonVariable> ...

这似乎是一种不好的做法，因为 Cucumber 本身就是一个值得商榷的 REST API 测试工具，但现在我想为该功能添加变量。但是，我有一些功能是 5-10k 行（分成多个文件），我估计我可以将其减少到 500-1k 行，并使其更具可读性。唯一的问题是测试编写器/读取器现在必须将 JSON 变量保留在他们的脑海中，但测试足够短，一次只能有 2 或 3 个变量。

【问题讨论】：

请问您使用 Cucumber 有多久了，您使用什么语言来实施您的项目？顺便说一句，征求意见不是 SO 正在寻找的问题。您可以考虑重新措辞，以便有人可以提供客观答案而不是主观答案。
@JamesB.Byrne 我已经使用 Cucumber 大约 3 个月了。我们的核心代码是用 Java 编写的，但是我们用 Cucumber 和 Ruby 来测试我们所有的 REST 服务。由于我们没有官方的 QA 团队，所有开发人员都在编写 Cucumber 测试，我想让我们更轻松。
您可能希望阅读一些与 BDD 和 Cucumber 相关的文档。你可以看看这个：github.com/cucumber/cucumber/wiki/Cucumber-Backgrounder 这是我对这个主题的看法。基本上，借用一句话：elabs.se/blog/15-you-re-cuking-it-wrong。
为了让自己更轻松，您需要退出当前的方法，并考虑 Cucumber 应该为您的项目带来什么价值。生成 1K 行特征文件是一个很好的线索，表明您的团队没有理解重点。
有趣的是，一旦你问如何做不可能的事情，人们就会开始质疑你的动机；说你不了解这个工具。

标签： json ruby automation cucumber bdd

【解决方案1】：

Cucumber 的重点是允许在功能文件中的每个场景中使用简单的英语表达 WHAT 应该发生的事情。步骤文件中详细说明了如何发生的。您在功能说明中添加了太多细节。这将是一场噩梦，因此很可能不会。具有可预测的结果。

一个场景应该是这样的：

Scenario The first thing our REST service does
  Given I have a REST service  
  When I connect with request "something" 
  Then I should get this result

在步骤文件中，您使用匹配器进行设置：

Given(/I have a REST service/i) do
   j_element = 'first value'
   . . .
end

请求在匹配器中指定：

When(/I connect with request "(.*)"/i) do |something|
  # Set new value
  j_element = something
  #send jason call 
  . . .
  return @result_set = visit( rest_api_path( j_element ) )
end

并在匹配器中检查结果：

Then(/I should get this result/i) do
   check_result( result_set )
   . . .
end

由于直接在方法之间随意传递实例变量不被认为是好的形式，因此您应该在步骤文件中定义访问器方法以优雅的方式处理此问题。

def result_set()
  @result_set ||= 'nothing set yet'
end

将在多个地方使用的测试放在他们自己的方法中，并将您想要检查的内容作为参数传递。

def check_result( result )
  assert . . .
  #or
  result.j_element.should . . .
 end

您当前放入功能文件的所有详细内容都应该放在匹配器后面的 do-end 块或辅助方法中（例如 check_result 和 result_set）。这使读者更清楚地了解您的场景应该完成什么，这也将帮助您简化步骤。

【讨论】：

【解决方案2】：

Cucumber 是用于执行 BDD 的工具而不是测试工具，尤其不是用于进行详尽测试的工具。对于你正在做的那种测试，你最好使用像 RSpec 这样的单元测试工具。因为单元测试/规范是用编程语言编写的，所以添加变量、循环等以进行大量测试很容易。

编写功能/场景的原因是描述行为，即你在做什么，也许更重要的是，你为什么这样做。您的场景实际上并没有这样做，而是非常详细地记录了您如何使用您的 api。要使用 Cucumber 开发您的 api，您应该以更抽象的方式编写场景，例如

Scenario: I can create a book
  Given I am an author
  When I create a book
  Then I have a book

请注意，这个场景没有任何关于这本书是如何创建的细节，没有提到 json，甚至没有提到 api。

TL/DR 将您现有的场景转移到一个单元测试工具中，并在那里引入您的变量和循环。您不能/不应该在功能文件中“编程”。

【讨论】：