[rspec-users] Stubs breaking other things

David Chelimsky dchelimsky at gmail.com
Wed Dec 13 05:07:35 EST 2006

On 12/13/06, David Chelimsky <dchelimsky at gmail.com> wrote:
> On 12/12/06, David Goodlad <dgoodlad at gmail.com> wrote:
> > Hi All
> >
> > I'm working on converting some existing controller specs to use mocks
> > and stubs rather than real ActiveRecord objects in a Rails project.
> > In one of my controller actions, I use a database transaction.  So,
> > the obvious thing to do is have this in my setup block:
> >
> > Project.stub!(:transaction)
> >
> > Firstly, is there an easy way to have that stub yield to the block
> > passed to any #transaction calls?
> Stubs won't do this right now (feel free to add an RFE saying they
> should), but you can do this w/ a mock. Just set it to
> any_number_of_times and it works just like a stub:
> Project.should_receive(:transaction).any_number_of_times.and_yield(whatever_you_like)

I went ahead and added this support directly to stubs as of rev 1284.


> > I'm sure there's an easy way to do
> > it but I can't seem to find it.
> >
> > Secondly, it seems that stubbing the transaction method in one context
> > breaks all sorts of other stuff.  I'm assuming that since AR uses
> > transactions for saving records, any project that gets saved in code
> > that actually uses the real Project model instead of a mock is now
> > broken.  Is the stub code, in the case of a partial mock, supposed to
> > revert any methods it overrides upon teardown?
> It is supposed to, and there was a problem with this a while ago, but
> we *believe* that we fixed it in 0.7.4. Which version are you using?

More information about the rspec-users mailing list