Skip to content

Conversation

@trinistr
Copy link
Contributor

@trinistr trinistr commented Dec 19, 2025

From #1016

When defining a class/module directly under the Object class by class/module
statement, if there is already a class/module defined by Module#include
with the same name, the statement was handled as "open class" in Ruby 3.1 or before.
Since Ruby 3.2, a new class is defined instead. [Feature #18832]

3fe6747 added tests for not reopening a Module, but not a Class.

This PR adds two missing tests:

  • not reopening an included Class,
  • class raising when constant is a Module (similar test exists in module_spec).

Update: also tests for reopening modules and classes inside other modules and classes.

Comment on lines 45 to 57
it "raises TypeError if constant given as class name exists and is not a Module" do
-> {
class ClassSpecsNumber
end
}.should raise_error(TypeError)
}.should raise_error(TypeError, /\AClassSpecsNumber is not a class/)
end

it "raises TypeError if constant given as class name exists and is not a Class" do
-> {
class ClassSpecs::IncludedInObjectWithClass
end
}.should raise_error(TypeError, /\AIncludedInObjectWithClass is not a class/)
end
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe this should be a single test? Behavior is exactly the same, but there could be semantic differences between a Module constant and a non-Module constant.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, as for me it makes sense to have them separate.

@trinistr trinistr force-pushed the test-class-not-reopening branch from afe799b to f0b43d2 Compare December 19, 2025 11:34
@trinistr trinistr marked this pull request as ready for review December 19, 2025 11:41
-> {
class ClassSpecs::IncludedInObjectWithClass
end
}.should raise_error(TypeError, /\AIncludedInObjectWithClass is not a class/)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

suggestion: it makes sense to have a separate fixture module and not to reuse IncludedInObjectWithClass as far as it introduces unnecessary coupling between two tests.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

suggestion: I haven't found any test that would check the same behaviour in general (that's not specific to Object). It makes sense to have such tests for module and class keywords.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added tests in non-Objects, though the test descriptions aren't great. I'm actually not sure if there was a difference in old versions between defining a module in top scope and explicitly inside Object (have a feeling there was a difference).

end
class Object
include ClassSpecs::IncludedInObjectWithClass

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure whether it's a good idea to touch Object - this may affect any other test case. As an option we can extend Object in a subprocess (see usage of ruby_exe helper).

Existing Object reopening comes from 2008 so I wouldn't use it as an example of a good testing practice.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should've checked when were the tests written 😅 I've also redone the Module test to reduce pollution.

@trinistr trinistr force-pushed the test-class-not-reopening branch from f0b43d2 to 0d34ba7 Compare December 21, 2025 22:56
@trinistr trinistr changed the title Add more tests for reopening classes Add more tests for reopening classes and modules Dec 21, 2025
@trinistr trinistr force-pushed the test-class-not-reopening branch from 0d34ba7 to 5bc0088 Compare December 21, 2025 23:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants