【问题标题】:Cucumber, calling Steps from other step. Best practise?黄瓜,从其他步骤调用步骤。最佳实践?
【发布时间】:2015-12-15 01:22:42
【问题描述】:

我今天和一位同事进行了深入的讨论。调用另一个步骤是否被认为是最佳实践? 所以,例如:

Given /a turtle/ do
  puts "turtle!"
end

Given /two turtles/ do
  step "a turtle"
  step "a turtle"
end

在我看来,这意味着您不能在不检查整个项目的情况下更改功能文件。因此,如果我想保持 DRY,我更喜欢使用从这些步骤调用的“代码”函数(即在 Ruby 中)。

def turtle do
   puts "turtle!"
end

Given /a turtle/ do
  turtle
end

Given /two turtles/ do
  turtle
  turtle
end

如果没有选择,我什至更喜欢复制代码而不是调用其他步骤。

Given /a turtle/ do
  puts "turtle!"
end

Given /two turtles/ do
  puts "turtle!"
  puts "turtle!"
end

什么是最佳实践,为什么?

【问题讨论】:

  • 你说的是nested steps?如果可能,我建议发布示例代码。
  • 我经常听到在步骤中使用调用函数,并在更通用的步骤中使用多个函数调用。

标签: cucumber gherkin


【解决方案1】:

嵌套步骤是一种非常糟糕的做法。如果你这样做,你很快就会陷入混乱。一个好的步骤定义是对方法的单行调用。其他任何事情都会很快变得混乱

考虑:

   When "I login" do
      visit login_path
      fill_in ...
      ...
      submit
   end

   When "I login as as admin" do
     visit admin_login_path
     fill_in ...
     ...
   end

看看如何立即出现重复。现在你可以通过逐步嵌套和传递参数来移除它,但是你最终会得到一个很难调试的非常复杂的步骤定义,所以只需调用一个辅助方法

   When "I login" do
     login user: @i
   end

   When "I login as an admin" do 
     login user: @i, role: admin
   end

我们在这里所做的只是将步骤定义用于一个简单的任务,将场景中的一行转换为方法调用。所有复杂的东西现在都采用标准方法。编程语言擅长处理复杂性。当我们编写登录方法时,我们将拥有各种可用的工具和技术,因此我们可以在保持代码 DRY 的同时管理任何复杂性。

【讨论】:

    【解决方案2】:

    最好这样使用

    功能

    Given "2" turtles
    

    步骤定义

    Given / "(\d+)" turtles/ do | count |
      count.times.do
        puts "turtle!"
      end
    end
    

    【讨论】:

    • 我知道。该示例的目的是更好地解释问题。问题是:从其他步骤调用步骤被认为是最佳实践?
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2018-05-20
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2012-10-06
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多