Apologies as this feels like an FAQ, but the only answer I can find refers to a
bug in a much earlier version of rspec, and this feels like a common thing to
do, so I suspect we're doing something stupid.
The issue seems to be that if we mock a class, that mock carries between specs
when runnin
>Unless RSpec is doing some magic under the hood that I'm not aware of,
>this is expected behavior - you're reassigning the constant value of
>MachineInstance.
>What you really want to do is mock/stub directly on MacineInstance. e.g.
>MachineInstance.should_receive(:create).and_return @mock_ma
>This is not an rspec bug :)
I thought not :-)
>This is assigning the value mock("MachineInstance") to the constant
>MachineInstance, which an interesting way to approach stubbing a
>class, but not really the idea.
>Can you show us the spec this is in so we can make appropriate recommendations
>That's the way Ruby behaves, yes.
>Once you assign the constant MachineInstance to point to your mock,
>Rails' magic auto-file-loading which normally happens when Ruby fires
>a 'missing constant error' will never run, so your real class will
>never get loaded.
>Assigning constants in you
>No, because RSpec keeps track of partial mocks (mocks/stubs on "real"
>objects) and clears them out at the end of the example run.
Thank you! This is the key, along with understanding we can just mock/stub
onto the real object, without needing to make the object a mock object.
As soon as we j
