[rspec-users] Newbie: lambda do...end.should change(Model, :count).by(1). Doesn''t work

CarmineM
2008-05-11T15:16:49Z

First off, thanks for your help and time and hints!

[...snipped some code...]
> You expect the database count to change, but because you mock away the
> method :save,
> the object won''t get saved. You don''t need to test for
Album#count to
> increase; if the ''save'' method is called
> for the object, you can rest assured there''s one more object in
the
> db. And if save doesn''t work as it should, the problem
> isn''t in your code but in the ActiveRecord instead.

> I''m not sure, but I guess that people who make this kind of
mistake
> think that mocking/stubbing a method doesn''t
> prevent the calling of the original method, but it does.

My fault, the code posted was my last (desperate I dare to say)
attempt to
get the whole thing work.
In the first "version", it doesn''t have a stub/mock on
"save" method,
still it didn''t
worked the way I expected. (Put aside the fact that I shouldn''t be
testing the ActiveRecord''s
code, which is a profound truth :) ).

In my case I''ve been fooled by the "should_receive" thing.
Being that
an expectation, to me,
only meant that the system was being checked about that particular
event (the call to save) to occur.

I didn''t pay much attention to the fact that
"should_receive(:save).and_..." wasn''t only about
expectation.  I thought that after the expectation being met, the
regular "save" method was
to be called.

That''s why I choosed "mock_model" over the regular (and more
generic)
"mock".

> The whole idea in mocking is to specify _expectations related to
> behaviour_. The following (simplified) rule could
> be stated as follows: if you use mocks, you don''t need to (nor
should)
> use state-based assertions, as
>  lambda {...}.should change(Model, :method) does. And vice versa; if
> you use state to test stuff, you don''t use mocks. But as
> I said, it is an oversimplification. For example, usually you
don''t
> want to mock or stub methods to unit/thingy under the test, but
> you _should_ probably mock/stub methods related to associated classes.
>
> That said, some people consider use of mocks dangerous and brittle to
> changes. I don''t - if you have a language terse
> enough (like Ruby) and an advanced speccing framework (like RSpec),
> changing your tests to reflect intended changes to code
> is not a chore too tedious for me. Besides, to ensure at least
> mediocre test/spec coverage you should automate your integration tests
> as well, where you don''t use mock/stub objects at all (with the
> exception of very expensive/non-deterministic resources such as say,
> network and random number generators).
>

[...snipped tips on how to learn BDD...]
Thanks for the pointers and tips. I will read first Fowler''s article
and
the other you mentioned, then I''ll try to see if things get better.
BDD is something I can''t "afford" to use at work, and so
I''m trying at
home
during "spare time", using my website as a testbed before attempting
writing a "real" application.

Again, thanks for your help!
Regards,
Carmine