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? 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? Thanks Dave -- Dave Goodlad dgoodlad at gmail.com or dave at goodlad.ca http://david.goodlad.ca/
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''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?
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. Cheers, David> > > > 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? >
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 -- Dave Goodlad dgoodlad at gmail.com or dave at goodlad.ca http://david.goodlad.ca/