RSpec: describe, context, feature, scenario?

describe, context, feature, scenario: What is the difference(s) among the four and when do I use each one?

32480 次浏览
小开
最佳答案

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

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

Personally I like to use describe, but I can see why people prefer context.

feature and scenario are a part of Capybara, and not RSpec, and are meant to be used for acceptance tests. feature is equivalent to describe / context, and scenario equivalent to it / example.

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

小开

今天早上，我在写一些说明书的时候，也有同样的问题。通常，我主要使用 describe，并没有特别考虑到这一点，但是今天早上我要处理一个模块的许多情况和不同的规范，所以它必须是容易理解的下一个开发人员将阅读这些规范。于是我问谷歌这个问题，我发现了这个: 在 rspec 中描述与上下文，我觉得它的答案很有趣:

根据 rspec 源代码，“ context”只是“ description”的别名方法，这意味着这两种方法在功能上没有区别。然而，上下文的不同将有助于通过使用这两种方法使您的测试更易于理解。

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

所以，根据这个原理，你可以写一个这样的规范:

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

不确定这是否是一个普遍接受的规则，但我发现这种方法很清楚，也很容易掌握。

小开

扩展皮埃尔的 答得好，根据 去找医生:

DSL 所描述的特性和场景, 这些方法只是允许特征的别名 规格阅读更多作为客户和验收测试。

因此，对于那些熟悉摩卡术语描述和它(它更适合从用户的角度描述测试行为，因此摩卡主要作为前端测试框架)的人来说，你可以:

  • 选择始终和只使用 describe和 it或其他配对
  • 选择在需要在特定应用程序状态下进行多个断言/测试的 context块中使用 it

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

因此，您的测试可能是这样的:

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

This way you skip the feature keyword entirely, which you might want to use for specific front end features or if you are doing FDD (feature driven development), which may feel uncomfortable for some. Ask your developer team for input here.

警告: 不要总是遵循行业标准，想象一下，如果我们所有的测试都仿效大众的理念？


提交答案