Thanks David,
This is just indicative of a big problem I think all my tests have. I
rarely/never use fixtures or the ORM for models that I'm not directly
testing. I just can't bring myself to do. Instead I tend to stub and
mock things out like above. The consequence is that all my specs (of
which there are a lot) are very tightly bound to the implementation
rather than the behaviour and as such are very brittle.
If a show action contains this (old Rails I know)
@thing = Thing.find(:first, :order => "created_at DESC")
I'll end up stubbing it out with
@thing = mock_model(Thing)
Thing.stub!(:find).with(:first, :order => "created_at
DESC").and_return(@thing)
which obviously breaks as soon as someone refactors.
I don't know ... maybe I'm just not a natural tester :(
Is everyone else using factories and fixtures these days or am I not
alone?
On Oct 24, 3:34 am, David Chelimsky wrote:
> On Oct 23, 2010, at 11:04 AM, deploy wrote:
>
>
>
>
>
>
>
>
>
> > I've been spec'ing for a long time, but I've never discovered the
> > answer to this, so a definitive answer would be great!
>
> > Whats the best way to spec a method which basically filters an
> > association?
>
> > class Thing < ActiveRecord::Base
> > has_many :others
>
> > def foos
> > others.all(:conditions => { ... })
> > end
> > end
>
> > I don't like the idea of creating a load of associated records in my
> > spec and testing the returned result as I am not testing the
> > associated model and as such would prefer any references to it to be
> > mocked out, so the best I can some up with is this super lame test
> > which is clearly way too implementation specific and essentially
> > useless.
>
> > describe Thing do
> > describe 'foos' do
> > before :each do
> > �...@thing = Thing.new
> > �...@others_proxy = mock('others proxy')
> > �...@others_proxy.stub!(:all)
> > �[email protected]!(:others).and_return(@others_proxy)
> > end
>
> > it 'should return the associated others which meet the conditions'
> > do
> > �...@others_proxy.should_receive(:all).with({ :conditions => ' ...
> > ' })
> > �[email protected]
> > end
> > end
> > end
>
> > So what's the best practice in this case?
>
>
> There are no 'best practices' absent _all_ of the context of the application,
> dev stack, dev team, other apps the team builds, etc. That aside ...
>
>
> When it comes to spec'ing filters, I tend to just use ActiveRecord (or
> whatever ORM I'm using). It's OK for some examples to hit the DB, and this is
> a good case for allowing it in my view, as the examples end up being more
> clear and readable and less brittle.
>
> HTH,
> David
>
> > Pastie is here for pretty formatting:http://pastie.org/1242892
>
> > Thanks.
>
> > P.S. This is old code I've inherited so I'm just trying to retrofit
> > RSpec 1.3x to it before I start refactoring and bringing up to date
> > with rails 3/rspec 2, so basically what I mean is what's the answer if
> > the model simply is how it is and can't be changed?
>
> ___
> rspec-users mailing list
> [email protected]://rubyforge.org/mailman/listinfo/rspec-users
___
rspec-users mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/rspec-users
