-
-
Notifications
You must be signed in to change notification settings - Fork 277
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
An error occurred while RSpec/ChangeByZero cop was inspecting #1983
Comments
… `change (...)`, concatenated with `and` and `or` fix: #1983
First of all, And, most importantly, shouldn’t this be - change(ClassA, :count) and
+ change(ClassA, :count).and Are you certain that the second matcher ever gets a |
Not certain at all. It was autocorrected as mentioned above. This should probably be disallowed in one of the rspec rules. |
Would you agree that this should be fixed on your side, and this cop does not necessarily have to consider this, @danielduan ? It might be an idea for another cop. Because, frankly, I was puzzled by this, wondering if this works or not with no doubt that I have never seen this syntax. What troubles me thought is that |
@pirj I do think cop should not throw errors on any valid syntax, which it looks like is being fixed and released. Whether we need a cop to separately manage the preference for and against this syntax format is up to you all. |
There is a distinction between a valid Ruby syntax, and sensible usage of RSpec DSL. I’d like to highlight that even though we’ve fixed the cop to tolerate valid Ruby syntax, we didn’t fully did that ( So, with that fix, we helped you and potentially other future users to write RSpec code that doesn’t do what it looks like doing. There is no cop to detect this. Before it’s created, I would rather have the existing cop to error out, and users to find this issue and having an idea that they have to fix their specs rather than living with deceitful specs until rubocop-rspec 3.0 where we enable new pending cops. |
Rubocop Rspec throws errors when the following line of code is inspected. I believe the AST tree does not take this code pattern into account:
We have multiple instances of this pattern and it errors on the last
end.not_to ... and ...
Expected behavior
This code is semantically correct so it should the AST should be able to crawl this code correctly.
Actual behavior
Describe here what actually happened.
Steps to reproduce the problem
Please see the code block above.
It was autocorrected from:
RuboCop version
The text was updated successfully, but these errors were encountered: