Mocking MiddleMan

I’m trying to verify (using expectations) that a backgroundrb job is
being started. I ran across this thread:
http://rubyforge.org/pipermail/rspec-users/2007-October/004115.html
, in which Pat M. conditionally loads backgroundrb. However, I
don’t see why the original construct that started the thread doesn’t
work:

MiddleMan
.should_receive(:new_worker).with(whateveryourparticularargumentsare)

What I’m observing is a failure connecting to dRuby, which makes sense
if MiddleMan is not mocked but (to me) does not make sense when it is
mocked.

I’d prefer not to change the actual init code for the plugin as Pat
suggests.

What am I missing about how this expectation should work?

Thanks

This is what worked for me back then:

In our spec_helper I did:

class Object; remove_const :MiddleMan; end
MiddleMan = Object.new

And then the spec looked like:

it “should call the admin email worker” do
MiddleMan.should_receive(:new_worker).with(:class
=> :admin_email_worker, :args => @email_params)
post_with_successful_send
end

and often MiddleMan.stub!(:new_worker)

HTH
Shane

On Mon, Jun 23, 2008 at 11:08 AM, s.ross [email protected] wrote:

I’m trying to verify (using expectations) that a backgroundrb job is being
started. I ran across this thread:
http://rubyforge.org/pipermail/rspec-users/2007-October/004115.html, in
which Pat M. conditionally loads backgroundrb. However, I don’t see why
the original construct that started the thread doesn’t work:

MiddleMan.should_receive(:new_worker).with(whateveryourparticularargumentsare)

What I’m observing is a failure connecting to dRuby, which makes sense if
MiddleMan is not mocked but (to me) does not make sense when it is mocked.

From what I remember, the problem is that backgroundrb starts some
stuff as soon as you reference MiddleMan. So even though you’re
stubbing the call to actually perform work, there’s some other stuff
that goes on behind the scenes before you’re even at that point.

Pat

On Jun 23, 2008, at 6:54 PM, Pat M. wrote:

From what I remember, the problem is that backgroundrb starts some
stuff as soon as you reference MiddleMan. So even though you’re
stubbing the call to actually perform work, there’s some other stuff
that goes on behind the scenes before you’re even at that point.

Right. That was it. I used your workaround, but Shane’s seems sensible
to try because we’re currently using an older version of backgroundrb
(one dev is on Windows and there are apparently no binaries available
for the current version). If Shane’s solution works, it should future-
proof us a bit because I won’t have to modify the plugin’s init.rb.

Thanks to both of you!