How to Test Method Alias Ruby

How to test method alias ruby

You can use Object#method.

Test.method(:b) == Test.method(:a)

Is there an elegant way to test if one instance method is an alias for another?

According to the documentation for Method,

Two method objects are equal if that
are bound to the same object and
contain the same body.

Calling Object#method and comparing the Method objects that it returns will verify that the methods are equivalent:

m.method(:bar) == m.method(:foo)

How to test `alias_method`?

The answer you shared the link for discusses about class methods, here you have instance methods. and yes, as correctly pointed out by @HoMan in the comments, following should work..

class User
  def username
    self.name.split(' ').first.downcase
  end

  alias nickname, username
end

In you testcases,

user = User.last
user.nick_name == user.username

Check if a method is an alias to another method in rspec

The definition of Method#== is not clear and/or useful, so you shouldn't rely on it.

To check that it is an alias, you can do this:

expect(subject.method(:to_archive).original_name).to eq(:archived!)

Ruby: check if method is defined before aliasing

what about

if Test.method_defined? :my_print
    alias_method :old_print, :my_print
end

Ruby: alias_method for module static method

Test.singleton_class.send(:alias_method, :bar, :foo)
Test.bar("cat")
  #=> "Test Foo with cat"

Testing an association with an alias_attribute

I wouldn't recommend using alias_attribute for that purpose. As far as I'm aware, shoulda uses ActiveRecord::Reflection to investigate associations. The only thing alias_attribute does is create methods to proxy messages from the target to the origin through getter, setter and '?' methods. It was clearly intended to work with ActiveRecord attributes and not general purpose methods.

The effect of that is that alias_attribute won't register those targets as ActiveRecord associations and the current implementation of shoulda won't be able to catch them.

There are also side effects to that pattern. As you might know, when you create an association, ActiveRecord also creates helper methods to make your life easier. For instance, a belongs_to also creates:

build_association(attributes = {})
create_association(attributes = {})
create_association!(attributes = {})

By your example, using alias_attribute won't give you album.build_album_type and that's something other contributors may be willing to rely upon, as they expect that to be the default behavior.

The best way to handle this is precisely what you told you wouldn't like to do, using the belongs_to method to create the association under the name you really want.

Is it possible to identify aliased methods in Ruby?

In Ruby 1.9, aliased instance methods will be eql?, so you can define:

class Module
  def aliased_methods
    instance_methods.group_by{|m| instance_method(m)}.
      map(&:last).keep_if{|symbols| symbols.length > 1}
  end
end

Now if you try it, you will get:

class Foo
  def bar; 42 end
  alias baz bar
  def hello; 42 end
end

Foo.aliased_methods # => [[:bar, :baz]]

Array.aliased_methods # => [[:inspect, :to_s], [:length, :size]]

Note that some pairs are missing, e.g. [:map, :collect]. This is due to a bug that is now fixed and will be in the next version (2.0.0) If it is important to you, you can roll your own group_by without using hashes or eql? and only using ==.

How can I dynamically define an alias method for a class method?

So just learned that this will do the trick:

module Calculator
  def memoize
    define_singleton_method(name, method(name))
  end
end

Then when Calculator gets included in Product it will define the singleton method as I needed. I still don't know why alias_method needs to only work on instance methods.. and I don't know why class_eval or instance_eval didn't solve the problem.. but at least I have a solution..

When should I use an Alias Method? - Ruby

I think this is from an earlier question I responded to, where I proposed using alias_method, so I have a little bit of extra context into this to explain it's use in that context.

In your code snippet, you have a bit of code that reads attr_reader :thirsty that is basically a getter for an instance variable of the same name (@thirsty)

def thirsty
  @thirsty
end

In the original code snippet, you had an assertion that was:

refute vampire.thirsty?

You also had code that simply returned true for thirsty? method, which failed your assertion.

There are at least two ways you could have modified your code so that the call to thirsty? worked and your assertion passed:

Create a method that calls the thirsty reader, or access the @thirsty instance variable itself:

def thirsty?
  thirsty # or @thirsty
end

The other way is to use alias_method, which is functionally equivalent to the above. It aliases thirsty? to thirsty which is an attr_reader which reads from the @thirsty instance variable

Reference to the other answer I gave

You might be better off not using an attr_reader at all, instead just doing as Sergio noted in his comment:

class Vampire
  def initialize(name)
    @name = name
    @thirsty = true
  end

  def thirsty?
    @thirsty
  end

  def drink
    @thirsty = false
  end
end

---

Related Topics