RSpec 中是否有与 Cucumber 的“场景”等效的内容？或者我使用 RSpec 的方式错误？

Question

Cucumber 场景的简洁性和实用性给我留下了深刻的印象，它们是测试大量不同案例的好方法。

例如示例 Cucumber 场景

Feature: Manage Users
In order to manage user details
As a security enthusiast
I want to edit user profiles only when authorized

Scenario Outline: Show or hide edit profile link
  Given the following user records
    | username | password | admin |
    | bob      | secret   | false |
    | admin    | secret   | true  |
  Given I am logged in as "<login>" with password "secret"
  When I visit profile for "<profile>"
  Then I should <action>

  Examples:
    | login | profile | action                 |
    | admin | bob     | see "Edit Profile"     |
    | bob   | bob     | see "Edit Profile"     |
    |       | bob     | not see "Edit Profile" |
    | bob   | admin   | not see "Edit Profile" |

（代码取自Ryan Bates' More on Cucumber Screencast)

RSpec 中有等效的吗？

我想在 RSpec 中做同样的事情，并通过将不同的测试减少到场景表中的一行。

虽然我可以自己编写代码来执行此操作，但我正在考虑它的事实让我想知道两件事

1. 如果这有用，它可能已经存在，在这种情况下我该如何使用它？

2. 如果它不存在，则表明不应该这样做，并且我错误地处理了这个问题，我应该如何重新考虑我的 RSpec 方法？

哪个答案是正确的，如果有用，我该怎么做？

Answer 1

我在问题 RSpec 场景大纲：多个测试用例。我给出了一种可能的解决方案，但如果您找到更好的解决方案，请告诉我。

Answer 2

我不会以这种方式使用 RSpec。 RSpec 应该用于将行为驱动到类中，一次一个小的行为。由于每种行为都是独特的，因此您应该使用不同的规范来定义它。

在上面的场景中，您可能有指定行为的规范，例如：

it "should allow user to edit his own profile"
it "should allow admin to edit other users profile"
it "should not allow non-admin to edit admin profile"
it "should not allow anonymous user to edit any profile"

还有一件事，使用 RSpec 驱动应用程序的多个层并不是一个好主意。换句话说，当您定义控制器时，您应该模拟与模型的交互等。

Answer 3

对于使用 RSpec 进行表驱动/参数化测试，现在有一些可能会有所帮助的宝石：

• RSpec:: WithParams - 用于参数化测试的 micro-DSL（披露：我是作者）
• RSpec： :Parameterized - 支持 RSpec 中的简单参数化测试语法

Answer 4

尝试以下方法。我喜欢它的结果。

describe StateDateMethods do
  before :each do
    @product = OpenStruct.new
    @product.extend StateDateMethods
  end

  def parse_date(unparsed_date_value)
    unless unparsed_date_value.nil?
      DateTime.strptime(unparsed_date_value, '%m/%d/%Y')
    end
  end

  context '#pre_order?' do
    examples = [
      # [visible_on, pre_order_on, for_sale_on] => method_result
      { :inputs => [nil, nil, nil], :expected => false },
      { :inputs => ['1/1/2001', nil, nil], :expected => false },
      { :inputs => ['1/1/2001', '1/1/2001', nil], :expected => true },
      { :inputs => ['1/1/2001', '1/2/2001', nil], :expected => true },
      { :inputs => ['1/1/2001', '1/1/2001', '1/2/2001'], :expected => false },
      { :inputs => ['1/1/2001', '1/1/2001', '1/1/3001'], :expected => true },
      { :inputs => ['1/1/2001', '1/1/3001', '1/2/3001'], :expected => false },
      { :inputs => ['1/1/3001', '1/1/3001', '1/2/3001'], :expected => false },
      { :inputs => ['1/1/2001', nil, '1/1/2001'], :expected => false },
      { :inputs => ['1/1/2001', nil, '1/1/3001'], :expected => false }
    ]
    examples.each do |example|
      inputs = example[:inputs]

      it "should return #{example[:expected].inspect} when visible_on == #{inputs[0].inspect}, pre_order_on == #{inputs[1].inspect}, for_sale_on == #{inputs[2].inspect}" do
        @product.visible_on = parse_date(inputs[0])
        @product.pre_order_on = parse_date(inputs[1])
        @product.for_sale_on = parse_date(inputs[2])

        @product.pre_order?.should == example[:expected]
      end
    end
  end
end

我认为这提供了两全其美的方法，因为它可以防止我重复自己，并且可以为每种情况创建不同的测试。

这是失败的样子：

....F.....

Failures:

  1) StateDateMethods#pre_order? should return false when visible_on == "1/1/2001", pre_order_on == "1/1/2001", for_sale_on == "1/2/2001"
     Failure/Error: @product.pre_order?.should == example[:expected]
       expected: false
            got: true (using ==)
     # ./spec_no_rails/state_date_methods_spec.rb:40:in `block (4 levels) in <top (required)>'

Finished in 0.38933 seconds
10 examples, 1 failure

Failed examples:

rspec ./spec_no_rails/state_date_methods_spec.rb:35 # StateDateMethods#pre_order? should return false when visible_on == "1/1/2001", pre_order_on == "1/1/2001", for_sale_on == "1/2/2001"

这是全绿色的样子：

..........

Finished in 0.3889 seconds
10 examples, 0 failures