Update RSpec/IteratedExpectation cop documentation with an example of a matcher relying on block arguments

[jprince]

This tripped me up but I was able to find a solution via #1206. Updating docs accordingly.

---

Before submitting the PR make sure the following are checked:

• Feature branch is up-to-date with master (if not - rebase it).
• Squashed related commits together.
• Added tests.
• Updated documentation.
• Added an entry to the CHANGELOG.md if the new code introduces user-observable changes.
• The build (bundle exec rake) passes (be sure to run this locally, since it may produce updated documentation that you will need to commit).

If you have created a new cop:

• Added the new cop to config/default.yml.
• The cop is configured as Enabled: pending in config/default.yml.
• The cop is configured as Enabled: true in .rubocop.yml.
• The cop documents examples of good and bad code.
• The tests assert both that bad code is reported and that good code is not reported.
• Set VersionAdded: "<<next>>" in default/config.yml.

If you have modified an existing cop's configuration options:

• Set VersionChanged: "<<next>>" in config/default.yml.

[jprince]

No problem. I’ll do so tomorrow morning when I’m back at my laptop. On June 7, 2023, zhangcaiyan ***@***.***> wrote: ***@***.**** commented on this pull request.

------------------------------ In CHANGELOG.md <#1659 (comment)>:

@@ -2,6 +2,7 @@

## Master (Unreleased) +- Update `RSpec/IteratedExpectation` cop documentation with an example of a matcher relying on block arguments. ***@***.***) No change log entry is required because the change is a document improvement and have no user impact. Can you remove this? — Reply to this email directly, view it on GitHub <#1659 (review)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAZ2GGRKQM5ER7TI75L6A4LXKE4MHANCNFSM6AAAAAAY6UWMNI> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[ydah]

Looks good!

[pirj]

Even though it’s a way to appease the cop, I wouldn’t say it’s readable.
I would suggest extracting the block part i to a custom matcher, or a helper method.
Personally, I’m opposed at documenting this as it is now to prevent this style from being widely used.

[ydah]

@jprince ping :-)

[jprince]

Apologies, I didn't realize you were waiting for my response. I don't disagree that the solution I documented is a bit difficult to read. However the current state is that the cop fails and the documentation provides no direction for how you can fix it - custom matcher or otherwise.

IMO it would actually be ideal if the cop ignored this scenario (admittedly I'm not sure how challenging it would be, technically). I think most of us would agree that the alternative (what I've documented here) is worse than .each/.have_attributes and I don't think the original issue (#278) had this scenario in mind.

[pirj]

Would the following work?
‘’’
expect([user1, user2, user3]).to all have_attributes(
‘’’

[jprince]

That would certainly be more readable, but unfortunately not in this scenario (where block arguments are used). The challenge is that the have_attributes call is receiving the user as an argument. It would raise "undefined local variable or method `user'"

[Darhazer]

IMO it would actually be ideal if the cop ignored this scenario (admittedly I'm not sure how challenging it would be, technically). I think most of us would agree that the alternative (what I've documented here) is worse than .each/.have_attributes and I don't think the original issue (#278) had this scenario in mind.

I agree that this is not a good use case for the all matcher and the original code might be a better fit. If @rubocop/rubocop-rspec agree with that direction, I'd be happy to make the change in the cop.

If we do not change the cop however, I agree it would be good to have the documentation. Even if a custom matcher might be a more elegant solution, we have to point to at least some way to write the spec.