Question

describe，context，feature，scenario：四者之间有什么区别？我何时使用每一种？

Answer 1

context是describe的别名，因此它们在功能上是等效的。您可以互换使用它们，唯一的区别是您的spec文件的读取方式。例如，测试输出没有区别。 RSpec的书说：

“我们倾向于使用describe()来表达事物而context()用于上下文”。

我个人喜欢使用describe，但我明白为什么人们更喜欢context。

feature和scenario是Capybara的一部分，而不是RSpec，并且用于验收测试。 feature相当于describe / context，scenario相当于it / example。

如果您正在使用Capybara编写验收测试，请使用feature / scenario语法，如果不使用describe / it语法。

Answer 2

今天早上，在写一些规格时，我遇到了同样的问题。通常，我主要使用describe而不是特别想到这一点，但是今天早上我处理的是一个模块的大量案例和不同的规范，因此下一个开发人员必须容易理解会阅读这些规格。所以我向谷歌询问了这个问题，我发现了这个问题：describe vs. context in rspec，我的答案非常有趣：

根据rspec源代码，“context”只是“describe”的别名方法，这意味着这两种方法之间没有功能差异。但是，有一个上下文差异，通过使用它们有助于使您的测试更容易理解。

“describe”的目的是针对一个功能包装一组测试，而“context”是针对同一状态下的一个功能包装一组测试。

所以，依靠这个原则，你可以编写一个这样的规范：

#
# The feature/behaviour I'm currently testing
#
describe "item ordering" do

  # 1st state of the feature/behaviour I'm testing
  context "without a order param" do
    ...
  end

  # 2nd state of the feature/behaviour I'm testing
  context "with a given order column" do
    ..
  end

  # Last state of the feature/behaviour I'm testing
  context "with a given order column + reverse" do
    ..
  end
end

不确定这是否是一个普遍接受的规则，但我发现这种方法很明确，很容易理解。

Answer 3

根据excellent answer，扩展Pierre的to the docs：

特征和场景DSL对应描述，分别。这些方法只是允许功能的别名规范以更多地了解客户和验收测试。

因此，对于那些熟悉Mocha术语描述及其（更适合从用户的角度描述测试行为，因此Mocha主要用作前端测试框架）的人，您可以：

选择始终且仅使用describe和it或其他配对
选择在需要在特定应用状态下进行多次声明/测试的it块内使用context。

使用第二个选项，您仍然可以遵循“ ...在相同状态下针对一个功能包装一套测试”的意图。

因此您的测试可能如下所示：

#
# The feature/behaviour I'm currently testing
#
describe "item ordering" do

  # 1st state of the feature/behaviour I'm testing
  context "without an order param" do
    # 1st and only test we want to run in this state
    it "asks the user for missing order param" do
     ...
    end
  end

  # 2nd state of the feature/behaviour I'm testing
  context "with an invalid order param" do
    # 1st test we want to run in this state
    it "validates and rejects order param" do
      ...
    end
    # 2nd test we want to run in this state
    it "returns an error to user" do
      ...
    end
  end

  # 3rd state of the feature/behaviour I'm testing with multiple tests
  context "with a valid order param" do
    it "validates and accepts order param" do
      ...
    end
    it "displays correct price for order" do
      ...
    end
    unless being_audited
      it "secretly charges higher price to user" do
        ...
      end
    end
  end
end

这样，您就完全跳过了feature关键字，您可能想将其用于特定的前端功能，或者如果您正在执行FDD（功能驱动的开发），这对于某些人可能会感到不舒服。请在这里向您的开发团队征询意见。

注意：不一定总是遵循行业标准，想像一下我们是否按照大众汽车的哲学模型对所有测试进行建模？

RSpec：描述，背景，特征，场景？

3 个答案: