-
-
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
Cop Idea: Prefer using the all
matcher instead of iterating over an array
#278
Labels
Comments
I think it should ignore negative expectations.
doesn't look right:
RSpec suggest defining negate matchers in such a case, but I don't think this is something the cop will be able to suggest |
backus
added a commit
that referenced
this issue
Mar 15, 2017
Implement RSpec/IteratedExpectation cop. Fixes #278
pirj
pushed a commit
to pirj/rubocop-rspec
that referenced
this issue
Nov 7, 2017
markburns
pushed a commit
to markburns/rubocop-rails-ddd
that referenced
this issue
Nov 7, 2017
markburns
pushed a commit
to markburns/rubocop-rails-ddd
that referenced
this issue
Nov 7, 2017
Implement RSpec/IteratedExpectation cop. Fixes rubocop#278
alecclarke
added a commit
to alecclarke/brew
that referenced
this issue
Oct 13, 2018
This change allows us to remove the `RSpec/IteratedExpectation` rule from `.rubocop_todo.yml` as we no longer iterate over each path to check existence. Note: We this PR didn't change the subsequent test checking for the negative expectations as this isn't part of the rule (see: rubocop/rubocop-rspec#278).
6 tasks
13 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The
all
matcher is pretty cool. We can't infer a lot of use cases statically of course but I bet we could probably detect enough cases for it to be useful. For example, I've seen some specs like thisthis could be written as
The text was updated successfully, but these errors were encountered: