matt-lists at reprocessed.org
Fri Mar 21 15:17:32 EDT 2008
On 19 Mar 2008, at 13:16, David Chelimsky wrote:
> On Tue, Mar 18, 2008 at 10:45 PM, Zach Dennis
> <zach.dennis at gmail.com> wrote:
>> On Tue, Mar 18, 2008 at 9:10 AM, David Chelimsky
>> <dchelimsky at gmail.com> wrote:
>>> It looks a lot like mock_model.
>>> stub_model(Person, :name => 'David')
>>> But it works in a fundamentally different way: FIrst, it creates a
>>> real instance (which means you have to create the model to use
>>> it). It
>>> assigns it an id by default, but you can set :id => nil if you
>>> want it
>>> to behave like a new record. It overrides new_record? so that it
>>> behaves as you would expect (false if there is an id, true if not).
+1 from me. I've been using a very similar approach for a couple of
months now, but I reopened ActiveRecord::Base instead and defined a
mock_saved Class method, so you can do:
Person.mock_saved(:id => 1, :name => 'David')
for a Person instance which pretends to be saved. I know that the
method name sucks, but I haven't been able to think of a better one...
>>> also overrides #connection, raising an error if there is any
>>> to access the database. This gives you the db isolation you get
>>> mock_model, but with a real object.
I'm not doing this, but I like it. (I think I shall steal it, post
> In general I agree, which is why it has taken me this long to arrive
> at this solution. The motivation for me, personally, is that with a
> mock object my view specs end up having to explicitly provide a lot of
> stub values that the examples are not interested. They are just noise
> that is present to keep the view moving.
I think I may be less averse to partial mocking than many people
(though I do worry about it), but I've found that this approach
allows me to be less explicit in my mocks and stubs, which is to say,
tying my tests less tightly into implementation specifics.
(However, this discussion has made me think that maybe I ought to
look at making .mock_saved make its instances more explody)
> Using a real model instance and mocking/stubbing only what I expect in
> a given example has allowed me to keep things much simpler in the view
> specs and so far they have caused me no pain. Perhaps the lack of pain
> has to do with the fact that views are generally not "interacting"
> with the model, per se. They are simply grabbing and displaying
> values. They are asking, not telling. Based on that, a mock object
> almost seems like a waste.
Absolutely. Explicit and painless. I stub out the associations
appropriately so I can test the various view cases, and it all seems
On a related mocking / stubbing noise / pain note, I've found that
Luke Redpath's Demeter's Revenge plugin (http://www.lukeredpath.co.uk/
2007/10/18/demeters-revenge) has become utterly essential for helping
untangle some of the more common cases of excess mock noise. (I tend
to deal with the others by moving towards many-skinny-methods).
Matt Patterson | Design & Code
<matt at reprocessed org> | http://www.reprocessed.org/
More information about the rspec-devel