Support Array.new(n) on RSpec/FactoryBot/CreateList cop

[r7kamura]

rubocop-performance's Performance/TimesMap cop autocorrects n.times into Array.new(n), so it would be nice if this cop supports autocorrection from Array.new(n) { create(:a) } to create_list(:a, n).

---

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 in default/config.yml to the next minor version.

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

• Set VersionChanged in config/default.yml to the next major version.

[Darhazer]

I guess we can merge the patterns, as they differ by the receiver

[Darhazer]

there's also first_argument method for send nodes ;)

[Darhazer]

I'd use some more generic name for this, like correctable_block? but I leave this up to you

[r7kamura]

I thought of that kind of name once myself, but I don't think it is necessarily correctable only by this condition.

If we create a method called #correctable_block?, the implementation should look something like this:

def correctable_block?(node)
  style == :create_list &&
    array_new_or_n_times_block?(node) &&
    node.body &&
    !arguments_include_method_call?(node.body) &&
    contains_only_factory?(node.body)
end

[bquorning]

I think I learned once that method names containing "or" or "and" should be avoided, and implemented as two methods instead. Would there be significant impact (readability, performance or other) if we chose to keep #n_times_block? and added an #array_new_block? matcher?

By the way, this doesn’t mean I think that block_with_arg_and_used? should be split 😄 But perhaps it could use another name?

[Darhazer]

Originally they were split, but since were so similar, I suggested having just one. We haven’t come up with a good name though

[bquorning]

Ah, sorry about that. I really should look at the previous conversations before I comment 😅

[ydah]

Perhaps, but it seems that adding an entry to CHANGELOG.md is not included in the pull request.
Please add an entry to the CHANGELOG.md .

[r7kamura]

I added a missing entry to CHANGELOG.md. Thanks!

[bquorning]

Can we give a name to the thing we call source on? That might allow me to think a bit less about what the method does 😅

Suggested change

	if node.receiver.int_type?
	node.receiver
	else
	node.send_node.first_argument
	end.source
	foo = if node.receiver.int_type?
	node.receiver
	else
	node.send_node.first_argument
	end
	foo.source

[r7kamura]

OK, I'll use the name count_node for this variable 👍

  3.times
# ^ this node

  Array.new(3)
          # ^ or this node

[bquorning]

@Darhazer Feel free to merge if you’re still happy with the changes.