instance_double not matching the same class it is mocking

[plukevdh]

I have a test case wherin an instance_double of a class does not think it is a kind_of/is_a/=== of the mocked class.

https://gist.github.com/plukevdh/7438f96ec0bd4dd65de8

May be related to issue filed/closed #749. Am I misunderstanding how this ought to work?

Currently using RSpec 3.1.5

[myronmarston]

This is by design. instance_double is meant simply to constraint your mocking and stubbing by the interface of the named class, but isn't meant to be an instance of the named class. They are meant to fit the same "role" as the named class, and provide the same interface, but not be the same class. You can use a partial double (e.g. a real object with a couple methods mocked or stubbed) to get something that is the same class.

[myronmarston]

To expand on this a bit more...besides the fact that instance_double isn't designed to work that way, there are also implementation difficulties: to make your spec pass, instance_double(MyClass) would have to stub MyClass#===, which would be a hidden, surprising stub. We don't want to do that.

[dmolesUC]

I don't think it's true that you can work around this with a partial double. Given the following:

class Foo
end

class Bar
end

class Baz
  def frob(x)
    case x
    when Foo
      'foo'
    when Bar
      'bar'
    else
      raise "expected Foo or Bar, got: #{x}"
    end
  end
end

require 'rspec'

describe Baz do
  describe '#frob' do
    it 'frobs a Foo' do
      foo = double(Foo.new)
      baz = Baz.new
      expect(baz.frob(foo)).to eq('foo')
    end
  end
end

I get:

Failures:

  1) Baz#frob frobs a Foo
     Failure/Error: raise "expected Foo or Bar, got: #{x}"
     RuntimeError:
       expected Foo or Bar, got: #[RSpec::Mocks::Double:0x3ff659d82db0 @name=#[Foo:0x007fecb3b05c78]]

In terms of test simplicity, if you don't need your 'mock' to do anything but you want to avoid some complex initialization, you can use Foo.allocate to create an 'empty' object of the correct class.

[myronmarston]

I don't think it's true that you can work around this with a partial double. Given the following:

You're example isn't using a partial double. (At least, it's not using what we mean by "partial double"). double(Foo.new) is not a partial double. It's a test double with Foo.new provided as the name.

Foo.new can be a partial double, and will be, as soon as you mock or stub a method on it.

In terms of test simplicity, if you don't need your 'mock' to do anything but you want to avoid some complex initialization, you can use Foo.allocate to create an 'empty' object of the correct class.

True, although Foo.allocate returns an object that has all the original implementations. In fact, it's identical to what is returned by Foo.new except for the fact that initialize has been skipped and it has no instance variables initialized.

[dmolesUC]

You're right, I totally failed to understand the partial double documentation. Sorry, coming out of Mockito where you have to wrap any real object before you can stub its methods. (The fact that the return values in the partial double docs are also doubles is confusing to newcomers, or at least this newcomer.)

If I wanted to stub MyClass#===, on purpose, out in the open with no surprises, how would I do it? There doesn't seem to be an obvious way to get the doubled class of an InstanceDouble.

[myronmarston]

If I wanted to stub MyClass#===, on purpose, out in the open with no surprises, how would I do it? There doesn't seem to be an obvious way to get the doubled class of an InstanceDouble.

You're right. Problem is, it doesn't really make sense to provide double.doubled_class on the verified double since the class it's doubling doesn't provide that interface. We may need to add a new API for this, although I'm not sure what it would be...

In the meantime, you could do this:

module VerifiedDoubleExtensions
  def instance_double(klass, *args)
    super.tap do |dbl|
      allow(klass).to receive(:===).and_call_original # do the normal thing by default
      allow(klass).to receive(:===).with(dbl).and_return true
    end
  end
end

RSpec.configure do |c|
  c.include VerifiedDoubleExtensions
end

This would make instance_double(MyClass) both create the instance double, and stub MyClass.=== to return true when passed the instance double.

[dmolesUC]

Clever! Thanks.

[fornellas]

@myronmarston , I understand an instance_double's design idea you explained, but if you look at Module#=== implementation, it actually calls the operand's kind_of? method. So, we can get a "full" behavior by:

let(:test) { instance_double(Integer) }
allow(test)
  .to receive(:kind_of?).with(Integer)
  .and_return(true)

Of course, other methods would have to be mocked also (#class, #is_a? etc). This could be another design approach ("instance_double_on_steroids"?!). What do you think?

[myronmarston]

@fornellas that sound like a good idea for an extension gem. If/when it sees significant usage by the community, we might consider rolling it in to RSpec in a future release.

[fornellas]

D'oh! Although Module#=== calls rb_obj_is_kind_of(), it in turn, does not seem to call the mock on the instance double. This approach does not work. One (hard) option would be to use a real object, created with BasicObject.allocate, and then, overwrite all existing methods on the class hierarchy, plus method_mising, to mimic instance_double. Even then, if the class hierarchy changes, things would break. We'd have to use hooks to protect against it.
In sum: hard to implement, easy to break. Not worth it.

[dmolesUC]

In practice I've mostly been able to work around it using MyClass.allocate instead of instance_double(MyClass).