[rspec-users] Stubs breaking other things

David Goodlad dgoodlad at gmail.com
Wed Dec 13 12:03:19 EST 2006

On 12/13/06, David Chelimsky <dchelimsky at gmail.com> wrote:
> On 12/12/06, David Goodlad <dgoodlad at gmail.com> wrote:
> > 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:

Right, I ended up finding this after I sent out my email; I just had
the idea in my head that I really wanted it to be a stub because I
didn't want to check that the call was made.  However, now that you've
added it to stubs, I'll probably go back to a stub when the next
release is made.

> > 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?

I'm using 0.7.4 (yes, matching rspec and rails plugin versions).  I'll
see if I can create a minimal test case to reproduce this.


Dave Goodlad
dgoodlad at gmail.com or dave at goodlad.ca

More information about the rspec-users mailing list