Improve RSpec/DescribedClass cop

[ydakuka]

Describe the solution you'd like

RSpec.describe Site do
  subject(:site) { create(:site, value: value) }

  # bad
  let(:value) { Site::MAX_VALUE }
  # good
  let(:value) { described_class::MAX_VALUE }

  specify do
    expect(site).not_to be_nil
  end
end

Rubocop

ydakuka@yauhenid:~/Work/project$ bin/rails_docker rubocop -V
1.57.2 (using Parser 3.2.2.4, rubocop-ast 1.29.0, running on ruby 2.7.8) [x86_64-linux]
  - rubocop-capybara 2.19.0
  - rubocop-factory_bot 2.24.0
  - rubocop-performance 1.19.1
  - rubocop-rails 2.22.0
  - rubocop-rake 0.6.0
  - rubocop-rspec 2.25.0
  - rubocop-thread_safety 0.5.1

[ydah]

We don't know if it is a class name or a constant name? For example, if we use Foo::A or Foo::HTML, we don't know whether A or HTML is really a class name or a constant name.

[pirj]

Do we care if the A const is assigned a class or a value? We only care about Foo here, and want to detect cases where it is used as a namespace like Foo::A, right?

[ydah]

Ah, I see. I was mistaken.

[timon]

This change makes a lot of our CI pipelines fail, with typical example being a gem autogenerated by bundle:

 RSpec.describe MyNewGem do 
   it 'has a version number' do 
     expect(MyNewGem::VERSION).not_to be_nil 
   end 
 end 

For things like these I would prefer full name for verbosity and explicitness.
Is there a way to configure this cop to still accept old style of referencing namespaced constants, besides having an engineer to go through this and manually putting a disable comment? (Yes, I'm aware of autocorrect — no, I don't want to autocorrect these)

[bquorning]

There’s the EnforcedStyle: explicit configuration option, as documented in https://docs.rubocop.org/rubocop-rspec/cops_rspec.html#rspecdescribedclass. There is not currently an option to enforce different styles for “stand-alone constants” (e.g. MyNewGem) vs namespaces (e.g. MyNewGem::VERSION).

[timon]

There is not currently an option to enforce different styles for “stand-alone constants”

:(

We prefer described_class in general. As it is not possible to make exceptions for nested constants I think we still have to go with autocorrect and change them to be described_class::VERSION

[bquorning]

…or temporarily disable the cop, or wait with the upgrade until @ydah or @ydakuka comments on this issue. 😄

[dduugg]

I would also like a configuration option to disable this change, as it breaks Sorbet type checking, which doesn't support dynamic constant references: https://sorbet.org/docs/error-reference#5001