[rspec-devel] stub_model

James Deville james.deville at gmail.com
Tue Mar 18 18:43:45 EDT 2008

+1 I think it sounds awesome. Especially since you get the speed of  
mocking by faking #connections, but you still get real behaviour!

On Mar 18, 2008, at 8:47 AM, Bryan Ray wrote:

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20080318/b52f795d/attachment.html 

More information about the rspec-devel mailing list