You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
describe"Something"dolet(:something_unrelated){"i exist"}subject(:named_subject){1}subjectdo2endit"should be 2"doexpect(subject).toeq(2)endend
And this reduced example command (assuming a config that requires rubocop-rspec):
bundle exec rubocop --only RSpec/MultipleSubjects,RSpec/LeadingSubject spec/example_spec.rb -a -d
This autocorrects to:
describe"Something"dosubject(:named_subject){1}let(:something_unrelated){"i exist"}it"should be 2"doexpect(subject).toeq(2)endend
Output:
Inspecting 1 file
C
Offenses:
spec/example_spec.rb:2:3: C: [Corrected] RSpec/MultipleSubjects: Do not set more than one subject per example group
subject do ...
^^^^^^^^^^
spec/example_spec.rb:4:3: C: [Corrected] RSpec/LeadingSubject: Declare subject above any other let declarations.
subject(:named_subject) { 1 }
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
spec/example_spec.rb:4:3: C: [Corrected] RSpec/MultipleSubjects: Do not set more than one subject per example group
subject(:named_subject) { 1 }
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
spec/example_spec.rb:5:3: C: [Corrected] RSpec/LeadingSubject: Declare subject above any other let declarations.
subject do ...
^^^^^^^^^^
I'm guessing the sequence of events is something like this:
RSpec/MultipleSubjects no-ops. Ordinarily, if executed alone it would turn the named subject into a let.
RSpec/LeadingSubject moves the named subject to the start of the block.
RSpec/LeadingSubject moves the unnamed subject to the start of the block:
describe"Something"dosubjectdo2endsubject(:named_subject){1}let(:something_unrelated){"i exist"}it"should be 2"doexpect(subject).toeq(2)endend
MultipleSubjects removes the unnamed subject because it will be overridden by the declaration of the named_subject.
This makes the test fail.
This was based on some relatively recent code (albeit a misuse of subjects). I agree with the autocorrect behaviour of MultipleSubjects in concept, but I'm not sure what should be done to prevent the conflict of these two cops.
The text was updated successfully, but these errors were encountered:
I think that's one possible option, and is probably the right one – I feel as though we should only avoid doing it if there are multiple subjects in the context, but I don't know how practical it is to suggest that. I've also considered:
Remove reordering of subject definitions entirely.
Get broader context of whether subject was called in the current context and use it to decide how to act here.
Mark LeadingSubject and/or MultipleSubjects as unsafe for autocorrect.
Have one cop act differently if another is being executed (unlikely to be possible).
Given this code:
And this reduced example command (assuming a config that requires
rubocop-rspec
):This autocorrects to:
Output:
I'm guessing the sequence of events is something like this:
RSpec/MultipleSubjects
no-ops. Ordinarily, if executed alone it would turn the namedsubject
into alet
.RSpec/LeadingSubject
moves the named subject to the start of the block.RSpec/LeadingSubject
moves the unnamed subject to the start of the block:MultipleSubjects
removes the unnamedsubject
because it will be overridden by the declaration of thenamed_subject
.This makes the test fail.
This was based on some relatively recent code (albeit a misuse of subjects). I agree with the autocorrect behaviour of
MultipleSubjects
in concept, but I'm not sure what should be done to prevent the conflict of these two cops.The text was updated successfully, but these errors were encountered: