class RuboCop::Cop::RSpec::IncludeExamples

it_behaves_like ‘examples’
# good
include_examples ‘examples’
# bad
@example
—-
end
end
expect(service.call).to eq “mocked response”
# Fails because ‘it_behaves_like` does not apply the mock setup
it “unexpectedly does not use the mocked service” do
it_behaves_like “mock behavior”
let(:service) { double(:service) }
context “broken example with it_behaves_like” do
end
end
expect(service.call).to eq “mocked response” # Passes
it “uses the mocked service” do
include_examples “mock behavior”
let(:service) { double(:service) }
context “working example with include_examples” do
end
end
expect(service.call).to eq “mocked response”
it “returns mocked response” do
end
allow(service).to receive(:call).and_return(“mocked response”)
before do
shared_examples “mock behavior” do
—-
[source,ruby]

access to `let` or `subject` values from the caller’s context.
In contrast, ‘it_behaves_like` creates a new context, preventing
access to their values.
`shared_examples` are evaluated in the caller’s context, allowing
When ‘include_examples` is used, `let` and `subject` defined within
Additionally, `let` and `subject` are affected by scoping rules.
correctly.
changes, which may prevent expected setup from being inherited
Specifically, the scope of hooks (`before`, `after`, `around`)
test failures.
context, altering setup dependencies, which can lead to unexpected
Changing `include_examples` to `it_behaves_like` creates a new
behaviors.
`include_examples` and `it_behaves_like` have different scoping
@safety
Prefer using `it_behaves_like` instead.
unexpected behavior and side effects.
within shared examples included with `include_examples` can have
own context. As such, using `subject`, `let`, `before`/`after`, etc.
`include_examples`, unlike `it_behaves_like`, does not create its
Checks for usage of `include_examples`.