RSpec: describe, context, feature, scenario?
The context
is an alias for describe
, so they are functionally equivalent. You can use them interchangeably, the only difference is how your spec file reads. There is no difference in test output for example. The RSpec book says:
"We tend to use
describe()
for things andcontext()
for 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
.
If you're writing acceptance tests with Capybara, use the feature
/ scenario
syntax, if not use describe
/ it
syntax.
This morning, while writing some specs, I was having the same question. Usually, I mainly use describe
and don't particularly think about this, but this morning I was dealing with lots of cases and different specs for one module, so it had to be easily understandable for the next developer that will read those specs. So I asked Google about this, and I found this: describe vs. context in rspec, whose answer I find quite interesting :
According to the rspec source code, “context” is just a alias method of “describe”, meaning that there is no functional difference between these two methods. However, there is a contextual difference that’ll help to make your tests more understandable by using both of them.
The purpose of “describe” is to wrap a set of tests against one functionality while “context” is to wrap a set of tests against one functionality under the same state.
So, relying on this principle, you'd write a spec like this:
#
# 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
Not sure if this is a generally accepted rule but I find this approach clear and quite easy to grasp.