[rspec-users] More on collection proxies

Jay Levitt lists-rspec at shopwatch.org
Wed Jan 24 08:45:55 EST 2007

David Chelimsky wrote:
> I'm kind of on the fence on this topic. I've been of the mindset that
> since models are so tightly bound to AR that it's more trouble than
> its worth to try and break that dependency. Because I mock models in
> all of my controller and view specs, I'm only hitting the db for the
> things that are interesting about models.

I think I'm of the same mind; I just wanted to make sure I wasn't taking 
the easy way out.

I was thinking... a great addition to rSpec someday - though a major 
project in its own right - might be a pre-stubbed version of 
ActiveRecord with fixtures.  Then again, that might be just as complex 
as the real AR, and maybe the solution is to just use an in-memory 
database when testing.
> Recently, I read a post from Jay Fields where he talks about what
> amounts to mocking out the loading of a file. So if you want to spec
> that User should validate presence of email, you do this:
> User.should_receive(:validates_presence_of).with(:email)
> load "${RAILS_ROOT}/app/models/user.rb"
> Odd, huh? It wouldn't be if the API for AR was like this:
> @model_registry.should_receive(:validate_presence_of).with(User, :email)
> User.register(@model_registry)
> Essentially, loading the file IS the entry point to the AR API.
> Interesting point of view, no?

Wow - I never thought of it like that.  I think (as a new convert to 
mocks) that type of mock is a little too specific and un-DRY for my 
taste, though; it feels like specifying that "line 6 of method foo 
should be an if statement".  There's double-entry bookkeeping, and then 
there's keeping two sets of books.

> So, no, I don't mind mocking the proxy in model specs, though I would
> always try to avoid that seeping out to the controllers and views.
> That helpful?


More information about the rspec-users mailing list