Skip to content
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

expect_correction & successive transformations #8075

Open
marcandre opened this issue Jun 1, 2020 · 2 comments
Open

expect_correction & successive transformations #8075

marcandre opened this issue Jun 1, 2020 · 2 comments
Labels
stale Issues that haven't been active in a while

Comments

@marcandre
Copy link
Contributor

As a followup to #8062, when testing for a cop that relies on successive autocorrections:

  • should we be more specific with spec'ing the intermediate steps?
  • or should we spec that a step leads to the expected correction (as @pirj suggests)?
  • or should we not always test only using the final stable step?
@bquorning
Copy link
Contributor

I have found only two specs (and both in the same file) that separately tests the result after one autocorrect and the result after looped autocorrects: https://github.com/rubocop-hq/rubocop/blob/774fe63486f6aa947dfe2e4f1d122c4fa48db080/spec/rubocop/cop/style/conditional_assignment_assign_to_condition_spec.rb#L46-L99 and https://github.com/rubocop-hq/rubocop/blob/774fe63486f6aa947dfe2e4f1d122c4fa48db080/spec/rubocop/cop/style/conditional_assignment_assign_to_condition_spec.rb#L2197-L2243

I have of course also found some tests that produce different results when looping autocorrects vs. running just one autocorrect. Some of these are quite silly, e.g. https://github.com/rubocop-hq/rubocop/blob/774fe63486f6aa947dfe2e4f1d122c4fa48db080/spec/rubocop/cop/layout/space_inside_array_literal_brackets_spec.rb#L522-L535 which says “Do not use space inside array brackets” and then promptly adds an offending space at the other end of the array.

@stale
Copy link

stale bot commented Nov 29, 2020

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contribution and understanding!

@stale stale bot added the stale Issues that haven't been active in a while label Nov 29, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
stale Issues that haven't been active in a while
Projects
None yet
Development

No branches or pull requests

2 participants