[rspec-devel] stub_model

Bryan Ray bryansray at gmail.com
Tue Mar 18 11:47:59 EDT 2008


Awesome. I've had a lot of trouble convincing my co-workers that straight
mocking is a very useful thing (integration testing always seems to take
precedence in my environment) ... and the "false positives" argument is
always brought up. I will definitely be taking a look at this.

+1 ... would love to hear any arguments against it though. I can't think of
any at the moment.

On Tue, Mar 18, 2008 at 8:10 AM, David Chelimsky <dchelimsky at gmail.com>
wrote:

> Hi all,
>
> Over the last couple of years I've read a ton of mail from users
> concerned with false positives coming from stubbing/mocking methods
> that don't exist. I recently added a stub_model method for
> rspec_on_rails (not yet released, available in git) which I think
> mitigates this a bit. It is still in development and subject to
> change, but here's how it works now.
>
> 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). It
> also overrides #connection, raising an error if there is any attempt
> to access the database. This gives you the db isolation you get from
> mock_model, but with a real object. Kind of like unit_record, but on
> an instance by instance basis.
>
> I've been using this for a few weeks now (just introduced it to the
> rspec code base a week or so ago) and I'm finding it very useful. I'm
> thinking of changing the generated rails specs to use stub_model
> instead of mock_model, and I'd be curious to hear your thoughts about
> this.
>
> Also - right now it checks the hash against the model's attributes. If
> the model has a matching attribute it gets assigned, otherwise a stub
> is created. It occurs to me that, with some modification, this *could*
> be used as a bit of an auditing/red-flagging tool. So let's say you do
> this:
>
>  stub_model(Person, :attrs => {:last_name => 'Name'}, :stubs =>
> {:full_name => 'Full Name'})
>
> In this case it would fail if the Person model changed :last_name to
> :given_name, for example. I have very mixed feelings about that, and
> might never use it myself, but it would serve to alleviate the fear of
> false positives.
>
> Thoughts?
>
> Cheers,
> David
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>



-- 
Bryan Ray
http://www.bryanray.net

"Programming today is a race between software engineers striving to build
bigger and better idiot-proof programs, and the Universe trying to produce
bigger and better idiots. So far, the Universe is winning."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20080318/556112fa/attachment.html 


More information about the rspec-devel mailing list