Skip to content

Conversation

@pirj
Copy link
Member

@pirj pirj commented Jan 11, 2020

Based on #855 by @dduugg


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.
  • Added an entry to the changelog 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).

@pirj pirj self-assigned this Jan 11, 2020
@pirj pirj requested review from Darhazer and bquorning January 14, 2020 19:11
].freeze

def_node_matcher :expect_literal, '(send _ :expect $#literal?)'
SUPPORTED_MATCHERS = %i[eq eql equal be].freeze
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it might be nice to have the option to add custom matchers in the configuration. This is another feature requests though

actual, matcher, expected = expect_literal(node)
lambda do |corrector|
return unless SUPPORTED_MATCHERS.include?(matcher)
return if expected.is_a?(Array) # `be` without args
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The comment is not precise, as arguments will also result in having an array. The :== case does not result in an array because of the $_ (while $... results in an array). So you are not correcting be, unless followed by ==

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice catch, the be with an argument case completely slipped my mind 👍
I assumed I'm using $... as a placeholder just to balance the number of captures in patter union clause, and it will always be [] for be.

@pirj pirj force-pushed the expect_actual-autocorrect branch 2 times, most recently from 3e94f0d to 701ccfe Compare January 14, 2020 22:01
describe Foo do
it 'uses expect incorrectly' do
expect(1).to be
^ Provide the actual you are testing to `expect(...)`.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, we don't have an actual here, and supporting this case complicates the pattern and the autocorrect code

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed.

@pirj pirj force-pushed the expect_actual-autocorrect branch from 7349a8a to 99be516 Compare January 15, 2020 11:39
Copy link
Member

@Darhazer Darhazer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The autocorrect might not be safe though. Maybe we can add SafeAutocorrect: false to the config, although we didn't provide the full meta data yet (but Safe and SafeAutocorrect are used by Rubocop, so at least it won't run this autocorrection in a Safe context)

#{Runners::ALL.node_pattern_union}
{
(send (send nil? $:be) :== $_)
(send nil? $:be $_)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the matcher below handles this case as well, as be is in the supported matchers

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fair enough, removed.

@pirj pirj force-pushed the expect_actual-autocorrect branch from 219f585 to f152aaa Compare January 15, 2020 12:21
@pirj pirj merged commit e76f7d4 into master Jan 15, 2020
@pirj pirj deleted the expect_actual-autocorrect branch January 15, 2020 12:43
@pirj
Copy link
Member Author

pirj commented Jan 15, 2020

Thanks, guys!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants