Finish branch coverage for RSpec/DescribedClass

[corsonknowles]

Finish branch coverage for RSpec/DescribedClass

Showing that the tested code evaluates:

zenpayroll(dev)* class MyClass3
zenpayroll(dev)> end
=> nil
zenpayroll(dev)> ("MyClass" + "3").constantize
=> MyClass3

zenpayroll(dev)* class MyClass3; class MyClass; end;
zenpayroll(dev)> end
=> nil
zenpayroll(dev)> (("MyClass" + "3").constantize)::MyClass
=> MyClass3::MyClass

Although at this point the math is superfluous -- (method_that_returns_a_class)::MyClass will cover this branch while method_that_returns_a_class::MyClass will not

Before:

After:

---

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: "<<next>>" in default/config.yml.

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

• Set VersionChanged: "<<next>>" in config/default.yml.

[bquorning]

(1 + 2)::MyClass generates invalid Ruby, since a module cannot be named 3. Can we can come up with a valid example that hits the else branch? Otherwise, if the code is unreachable, we can tell SimpleCov to ignore it with

          else
            # :nocov:
            raise "Invalid argument" # or similar
            # :nocov:

[corsonknowles]

Thanks @bquorning -- it works with a little magic sprinkled in, and it documents the behavior I think.

[corsonknowles]

It's possible there's another approach here to handle the s(:begin, block this example creates in the AST, but I don't know how it should handle that.

[bquorning]

This example still seems a bit far fetched 😅

[bquorning]

I’ll see in real-world-rspec if there’s any code that hits the branch you’re looking at.

[corsonknowles]

Not just far fetched, a little hard to find! A good puzzle.

I buried this in the updated description above, but the way we're getting past the case statement here is just by having a :begin node from the parentheses.

I replaced the example with a simpler parenthesized method call.

The weird thing is:
subject { method_that_returns_a_class::MyClass }
does get handled.

I'm not certain how method_that_returns_a_class or (method_that_returns_a_class) ought to be corrected, but maybe they should be handled identically.

[bquorning]

subject { method_that_returns_a_class::MyClass } makes namespace a send type, whereas subject { (method_that_returns_a_class)::MyClass } makes namespace a begin type. So maybe the test case we want is just explicitly having parentheses around the namespace?

[bquorning]

Btw I just found that changing line 85 from let(:baz) { foo::CONST } to let(:baz) { @foo::CONST } will raise an exception. Not sure if that is related at all, or should be a separate issue.

[corsonknowles]

Btw I just found that changing line 85 from let(:baz) { foo::CONST } to let(:baz) { @foo::CONST } will raise an exception. Not sure if that is related at all, or should be a separate issue.

Great find! Separate issue, but another perk of the exercise.

[bquorning]

Don’t forget to update .simplecov ✨

[corsonknowles]

I didn’t want to start a conflict cascade. I think we can change it to 100% when all of your PRs are merged?

…

On Sun, Feb 9, 2025 at 10:18 AM Benjamin Quorning ***@***.***> wrote: ***@***.**** commented on this pull request. Don’t forget to update .simplecov ✨ — Reply to this email directly, view it on GitHub <#2030 (review)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AANFDS5YWNIM4WLWMJO4XV32O6LXFAVCNFSM6AAAAABWYJTDI2VHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDMMBUGMZDQNZTGI> . You are receiving this because you authored the thread.Message ID: ***@***.***>