RSpec aliases runtime matchers

[sl4vr]

This is an attempt of implementation of issue #333 and evolution of PR #921. Allowing to configure 3rd partly DSLs as valid RSpec syntax.

Configurable language elements:

• Hooks
• Examples
• Hook scopes
• Includes
• Example groups
• Shared groups
• Helpers
• Subject
• Expectations
• Runners

---

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. (Add v2 update docs #1013)
• 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).

[sl4vr]

Looks like smoke tests fail, need to rewrite RuntimeMacros in a same manner like RuboCop's Macros are made.
Seems that smoke tests fail due to another reason, which should be fixed here: #955

[pirj]

Frankly, it looks great. All code review notes are minor nitpicks.

I'm concerned about two major things:

• performance impact: dynamic way to define matchers may cost us
• consistency: are we going to use this approach for all RSpec's DSL constructs

If there's no significant performance impact (e.g. on Discourse/GitLab specs suite runs), I'll be more than happy to merge this. We'll eventually catch up and rework other DSL elements to use this dynamic configuration.

[pirj]

@sl4vr Do you need some help with this?
Highly appreciate if you could at least come up with a PoC, I can take it from there if you like, or we can share the work if you like.

[pirj]

Looks good! 👏
Minor notes, mostly on how to keep the existing cops intact.
Eager to rework the rest in the same way and start hacking on adding the missing DSL pieces.

[sl4vr]

NodePattern is bloated a bit with similar methods, I would wait for all RSpec language parts implementation and then do something like:

{
  regular_examples: ['Examples', 'Regular'],
  focused_examples: ['Examples', 'Focused'],
  skipped_examples: ['Examples', 'Skipped'],
  pending_examples: ['Examples', 'Pending'],
  hooks: ['Hooks'],
}.each do |name, config_keys|
  define_method "rspec_#{name}" do |keyword|
    send("#{name}_set").include?(keyword)
  end

  define_method "#{name}_set" do
    instance_variable_get("@#{name}_set") ||
      instance_variable_set(
        "@#{name}_set",
        Set.new(rspec_language_for(*config_keys))
      )
  end
end

Because it highly depends on config and may change yet.

[pirj]

@bquorning True. Fixed this by tagging those specs :config, adding a cop to be investigated and calling on_new_investigation on this cop. It's kind of a trick to set Language for those specs that typically happens automatically when expect_offense conducts an investigation.
Specs in question were Concept specs (Example, ExampleGroup, Hook) that don't call expect_offense.

[pirj]

@bquorning Both this PR's build and #1007 that I've just rebased onto this are green.

[bquorning]

But how come the specs passed when run with the entire suite? Usually it means there is some global state being changed somewhere.

[pirj]

There is indeed global state, in Language.config that is assigned when the first cop is initialized and starts the investigation.

[bquorning]

This PR looks so much better now. I think we are getting very close to merging.

[bquorning]

By the way, how come that we changed from ExampleGroups::GROUPS to ExampleGroups#regular and from Examples::EXAMPLES to Examples#regular?

[pirj]

Hm. I lost track of this.
To me, "regular" sounds better. But we at least have to mention this in the update_to_v2 document.

[bquorning]

This code reads a bit weird. It looks like there’s a question mark missing, i.e. Examples.all?(ancestor.method_name), but that’s also not good.

Probably not something we need to fix now, but just an observation.

[pirj]

Indeed. Those new helpers fit patterns more.
I can think of adding an include? alias for all to all of them, however, this will not provide a similar interface to Examples.regular.

Another way is to check if an argument has been passed (used in a pattern), or not. If not - just return a list, and this will make both Examples.all.include?(ancestor.method_name) and Examples.regular.include?(ancestor.method_name) possible.

[bquorning]

Returning different types (boolean vs array) from the same method also isn’t great. Maybe we should call #all? from within out patterns? Also not really a great option :-/

I think we should just leave it for now.

[bquorning]

I… have run out of comments 😅

Thank you for the great work @pirj and @sl4vr. 🎉

Squash and merge at will.

[pirj]

@sl4vr Thanks a lot for implementing this. It is a huge amount of work, really, I now understand this after making subtle changes. It's time to claim your CoM trophy, but it's not all, you also get this symbolic golden RuboCop statuette:

@marcandre Thanks a lot for early-stage reviews, incredible suggestions and making changes to rubocop-ast that allowed this change to be made. You get a golden RuboCop statuette as well, and I guess it's not your first one!

[marcandre]

Thanks @pirj, you're too kind 😅
Congrats to @sl4vr, @bquorning and yourself for landing this 🎉

[sl4vr]

@pirj thank you for leading and finishing this PR 😅