Specs for aliased methods

[Earlopain]

Ruby has many methods that refer to exactly the same thing. For example Hash#include?/Hash#key?/Hash#has_key?/Hash#member?.

ruby-spec handles this via shared examples that then get run once for each method. This inflates the passing/failing spec rate, since there must never be different behavior between them. If one spec passes, it will pass for the others and same if it fails. It also gives indirection when reading the specs, mostly via passing the method name as a parameter to the shared examples.

My question is if this is good usage of shared examples. Wouldn't a better test look something like this?

it "it an alias of Hash#key" do
  # Checks that they are actually identical
  Hash.instance_method(:include?).should == Hash.instance_method(:key?)
end

One method would then inline the shared examples to actually run the tests. Which one tests for being an alias and which one runs the tests doesn't really matter, but to reduce debate it can be the one with the "real" implementation in MRI ("also aliased as" when viewing docs).

What do you think?

[eregon]

Yes, that would be nice and is a good idea.

The biggest hurdle was at least back then in many cases Hash.instance_method(:include?) == Hash.instance_method(:key?) would be false even though they are aliased or the same C function.
That seems to work better these days on 3.4 and 4.0:

irb(main):001> Hash.instance_method(:include?) == Hash.instance_method(:key?)
=> true
irb(main):002> Kernel.instance_method(:then) == Kernel.instance_method(:yield_self)
=> true

On 3.3 though:

irb(main):002> Hash.instance_method(:include?) == Hash.instance_method(:key?)
=> true
irb(main):003> Kernel.instance_method(:then) == Kernel.instance_method(:yield_self)
=> false
irb(main):007> Kernel.instance_method(:then).source_location == Kernel.instance_method(:yield_self).source_location
=> true

So maybe we could do it with a matcher that falls back to UnboundMethod#source_location if the UnboundMethod don't report true for ==.

I tried in the past something more complicated in ruby/mspec@88e734a and reverted it in ruby/mspec@b3e2274 because it felt too complicated to ignore automatically shared example in mspec.

I think doing it explicitly like you say is a better idea.

BTW there is already some manual version of this for the slowest cases:

spec/core/kernel/spawn_spec.rb

Lines 4 to 7 in 99d40d4

	# These specs only run a basic usage of #spawn.
	# Process.spawn has more complete specs and they are not
	# run here as it is redundant and takes too long for little gain.
	describe "Kernel#spawn" do

[eregon]

Kernel#spawn and Process.spawn is actually an interesting example, they are not aliases but they are very much the same.
In CRuby they are the same C function:
https://github.com/ruby/ruby/blob/f6886fc1ccde667845bd691cad18f8f32f00d312/process.c#L9197
https://github.com/ruby/ruby/blob/f6886fc1ccde667845bd691cad18f8f32f00d312/process.c#L9221

I don't find a way to prove they are the same on CRuby 4.0:

irb(main):001> Kernel.method(:spawn)
=> #<Method: Kernel.spawn(*)>
irb(main):002> Process.method(:spawn)
=> #<Method: Process.spawn(*)>
irb(main):003> Process.method(:spawn) == Kernel.method(:spawn)
=> false
irb(main):004> Process.method(:spawn).unbind == Kernel.method(:spawn).unbind
=> false
irb(main):005> Process.method(:spawn).source_location
=> nil

In TruffleRuby we could look at the source and this is what this code did.

BTW module_function like Kernel#spawn and Kernel.spawn also seem hard to prove they are the same:

irb(main):008> Kernel.method(:spawn).unbind == Kernel.instance_method(:spawn)
=> false

But, we could start with the case of regular aliases which can be detected as the same, that would still be a good improvement.
I just wish we could extend it to "methods which have the same definition but are not Ruby aliases".

[Earlopain]

On 3.3 though:

You picked a pretty bad example with then/yield_self because they weren't actually aliases back then! ruby/ruby#11757. So that not matching makes sense. Your last assertion should be false though, since they absolutely do have different source locations. It's ["<internal:kernel>", 129] <=> ["<internal:kernel>", 144] for me on 3.3.10.

Interesting to see you already tried something similar in the past and yeah, that seems a bit convoluted. It's an interesting approach but I understand why you reverted that.

spawn is not something I considered. Since they are not aliases I don't think there will be a way to prove this in an easy and obvious way currently. But overall such cases should be rare compared to the amount of real aliases.

Do you mind me experimenting with this? I can start out with a single case to see how it would look.