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
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
