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

CarmineM carmine.moleti at gmail.com
Sun May 11 11:16:49 EDT 2008

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)

> 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
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
during "spare time", using my website as a testbed before attempting
writing a "real" application.

Again, thanks for your help!

More information about the rspec-users mailing list