RSpec：描述，上下文，功能，场景？

describe，context，feature，scenario：什么是四间的差异（一个或多个），做当我使用每一个？

该context是一个别名describe，所以它们在功能上等同。您可以互换使用它们，唯一的区别是规格文件的读取方式。例如，测试输出没有差异。RSpec书中说：

“我们倾向于describe()用于事物和context()环境”。

我个人喜欢使用describe，但我可以理解为什么人们更喜欢context。

feature并且scenario是Capybara（不是RSpec）的一部分，并且意在用于验收测试。feature等价于describe/ context，scenario等价于it/ example。

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

今天早上，在编写一些规范时，我遇到了同样的问题。通常，我主要使用describe并且不特别考虑这个问题，但是今天早上我正在处理一个模块的许多情况和不同的规范，因此对于下一个阅读这些规范的开发人员来说，它必须易于理解。因此我向Google询问了这一点，然后发现了这一点：rspec中的describe vs. context，我的回答很有趣：

根据rspec的源代码，“上下文”只是“描述”的别名方法，这意味着这两种方法之间没有功能上的区别。但是，存在上下文差异，通过同时使用它们，将有助于使您的测试更易于理解。

“描述”的目的是针对一个功能包装一组测试，而“上下文”则是在相同状态下针对一个功能包装一组测试。

因此，根据此原理，您可以编写如下规范：

#
# 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

不确定这是否是一个普遍接受的规则，但是我发现这种方法清晰易懂。

根据文档，扩展了Pierre的出色答案：

功能和场景DSL分别对应于description和它。这些方法只是别名，它们使功能规格可以作为客户测试和验收测试阅读更多。

因此，对于那些熟悉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（功能驱动的开发），这对于某些人可能会感到不舒服。在这里向您的开发人员团队咨询。

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