I noticed that the examples on the rspec website for model code http://rspec.info/documentation/rails/writing/models.html have no mocks or stubs. However both the controller example and view example do have mocks and stubs implemented. I was having some problems getting mocks to work in my model (using mock_model and passing in a hash or stubs) but I''m wondering if I shouldn''t be mocking or stubbing in my model at all? I''ve done the googling on mocks vs stubs and read a bunch or info, I''m just wondring how some of the fellow rspec users implement mocking and stubbing in their specs and whether or not it is ok to mock and or stub in a model? Thanks, -Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20080819/b441dfed/attachment.html>
On Aug 19, 2008, at 9:38 AM, Jonathan Kinney wrote:> I noticed that the examples on the rspec website for model code http://rspec.info/documentation/rails/writing/models.html > have no mocks or stubs. However both the controller example and > view example do have mocks and stubs implemented. I was having some > problems getting mocks to work in my model (using mock_model and > passing in a hash or stubs) but I''m wondering if I shouldn''t be > mocking or stubbing in my model at all? I''ve done the googling on > mocks vs stubs and read a bunch or info, I''m just wondring how some > of the fellow rspec users implement mocking and stubbing in their > specs and whether or not it is ok to mock and or stub in a model? >Of course it''s OK to mock - but with that said, you should probably have some sort of "real" integration tests, which do touch the database. Ultimately, it''s all about convenience and your comfort level. The reason mocking is as popular as it is is simply because of slow test suites (google Dan Manges and unitrecord, if you are curious). Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20080819/848923c4/attachment.html>
On Tue, Aug 19, 2008 at 6:38 AM, Jonathan Kinney <jonkinney at gmail.com>wrote:> I noticed that the examples on the rspec website for model code > http://rspec.info/documentation/rails/writing/models.html have no mocks or > stubs. However both the controller example and view example do have mocks > and stubs implemented. I was having some problems getting mocks to work in > my model (using mock_model and passing in a hash or stubs) but I''m wondering > if I shouldn''t be mocking or stubbing in my model at all? >In a model spec, clearly you don''t want to mock any part of the model under test, because then you''re not testing it. However, anything else (including other models) is fair game. Mocks are used specifically to avoid testing something, usually because you (or someone else) is testing it elsewhere. Mocks make sure that the object under test is behaving correctly in its interactions with other code - but (in a unit spec, at least), you don''t want to redundantly or expensively also test that other code. That''s my take, at least ///ark -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20080819/b3df60ca/attachment.html>
It''s also, for me, nice to isolate the code I''m testing using mocks. So if I''m building a controller and I mock out the behaviour I will expect it to call on the model layer, I know that any failing tests must be due to bugs in the controller class, nowhere else. Coming from using an NHibernate / POCO stack in .NET where my domain (model) objects were completely de-coupled from their persistence behaviour, I''ve found it quite hard working with ActiveRecord objects. It seems like the path of least resistance when you''re working with objects that inherit from ActiveRecord::Base is just to put your TDD principles to one side, set up stock data in your database, call the model from your tests and forget about trying to mock anything out. Trying to get a mockable seam in between your own model logic and ActiveRecord''s persistence code seems to hard... at least for me at this stage of my ruby learnings. So, in summary, I guess I would advise you to mock wherever you can, unless you''re testing an object that inherits from ActiveRecord::Base. People draw the line in lots of different places though, so you''ll probably find other people much less keen on mocking than me. cheers, Matt ---- http://blog.mattwynne.net http://songkick.com In case you wondered: The opinions expressed in this email are my own and do not necessarily reflect the views of any former, current or future employers of mine. On 19 Aug 2008, at 15:08, Scott Taylor wrote:> > On Aug 19, 2008, at 9:38 AM, Jonathan Kinney wrote: > >> I noticed that the examples on the rspec website for model code >> http://rspec.info/documentation/rails/writing/models.html have no >> mocks or stubs. However both the controller example and view >> example do have mocks and stubs implemented. I was having some >> problems getting mocks to work in my model (using mock_model and >> passing in a hash or stubs) but I''m wondering if I shouldn''t be >> mocking or stubbing in my model at all? I''ve done the googling on >> mocks vs stubs and read a bunch or info, I''m just wondring how >> some of the fellow rspec users implement mocking and stubbing in >> their specs and whether or not it is ok to mock and or stub in a >> model? >> > > Of course it''s OK to mock - but with that said, you should probably > have some sort of "real" integration tests, which do touch the > database. > > Ultimately, it''s all about convenience and your comfort level. The > reason mocking is as popular as it is is simply because of slow > test suites (google Dan Manges and unitrecord, if you are curious). > > Scott > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20080819/aad36af8/attachment-0001.html>
On Tue, Aug 19, 2008 at 7:08 AM, Scott Taylor <mailing_lists at railsnewbie.com> wrote:> > Ultimately, it''s all about convenience and your comfort level. The reason > mocking is as popular as it is is simply because of slow test suites (google > Dan Manges and unitrecord, if you are curious). >Another reason why you''d mock out the database is that that''s not your code - it''s ActiveRecord and MySQL/PostgreSQL/etc (which one would imagine have been rather thoroughly tested elsewhere:). The idea is that if you know you''re calling ActiveRecord methods correctly, you don''t actually have to go any deeper than that in a unit spec. The key, I think, is to ask yourself "what am I testing/speccing?" Generally (again, for a unit test), it''s the contents of a file or files that you are writing - very often, a single method. You want to make sure that you''ve specified what the contents of that method do, and that the lines of code in it are correct. ///ark -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20080819/e83c5373/attachment.html>