-
-
Notifications
You must be signed in to change notification settings - Fork 118
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Confusing described_class
#104
Comments
I think I can elaborate by explaining how we use describe SomeModule do
it 'performs frobulation' do
result = described_class.frobulate(arg1, arg2)
end
end Sometimes we use it as an argument for We also often test classes that have specific arguments to the constructor, while So while I don't think I am voting with a 👎 because the wording of the issue implies a "class that can be instantiated", which is exactly something we do not have when testing callable modules, and which is not something |
I completely understand this point, @julik. What you describe is in the list of pros of
On a side note, be it a
It's one way to interpret it, though I did not intend to limit the focus of the problem to that specific case. |
I read you. It is a bit hard to argue that something that ends with What are the situations where |
Adding my 👎. I don't think |
I'd be okay with I'm not sure if I fully understand your 🚀 option, but I'd support rubocop-rspec enforcing that |
I'd like to have a fourth option, to keep I literally never ran in any of the issues. Maybe I have very solid testing hygiene (I doubt that), but I usualy
I'm hoping for rubocop to help me |
@arnoFleming I suggest you vote for 🚀 (enforce passing classes and strings exclusively as the first argument to example blocks).
It seems you really do. |
@dvandersluis RSpec itself has to support legacy testing code between major version updates, but RuboCop-RSpec can enforce good practices here and now, preparing the users for the future changes, and preventing from making mistakes without making the spec suite red. |
@julik It's innermost, not outermost. Agree that in shared examples the real value behind
I tend to think that "the thing under test":
|
@flanger001 It is a contrived example, but is demonstrating a real unfortunately. In case I've drafted a cop that on a test file results in:
Out of 13024 (spec) files from Real World Ruby apps there were no really no offences found with There were some cases with symbols being used as the first argument, but not many, just 60. This is not a recommended or canonical use, but is a matter of taste, and there's no real harm if Some examples below:
|
Closing as stale since there's no clear way RSpec is going with |
Hey, everyone!
described_class
is no doubt widely used in specs, there are 1376 usages in repositories listed inreal-world-ruby-apps
.According to
described_class
docs:However, in fact it's slightly different:
With one exception though, when a string is passed as the first argument.
One common mistake is passing metadata without a proper docstring, e.g.:
results in:
It may be unclear why the first argument is taken from the innermost example group, not outermost (
SomeClass
).There was a breaking change introduced in RSpec 3.0 to take the first argument of the innermost example group as
described_class
, not outermost.Unfortunately, this was not reflected in the docs (1, 2), and it's still not (it's on
master
but not on3-8-maintenance
), even after this pull request.There was an idea to change
described_class
's behaviour:Unfortunately, this idea was two weeks late for RSpec 3.0 release.
With all this confusion in mind:
Bottom Line
Pros of
described_class
:Cons of
described_class
:How to Deal with This
What do you think about introducing a guideline to discourage passing anything than a literal class and a string as the first argument to an example group?
React with a 🚀 if you agree.
Or would you be radical and discourage the use of
described_class
altogether, and recommend using class names explicitly?Place a 👍 if you decide to be explicit about what is being tested.
Please react with 👎 if you'd like to stick to
described_class
(at least until RSpec 4 is out).Highly appreciate if you add additional arguments pro and contra.
The text was updated successfully, but these errors were encountered: