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
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 M. and unitrecord, if you are curious).
Scott
On Tue, Aug 19, 2008 at 6:38 AM, Jonathan Kinney
[email protected]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
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
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 Tue, Aug 19, 2008 at 7:08 AM, Scott T.
<[email protected]
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 M. 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