[rspec-users] client first, top down, outside in, etc with rails

Nathan Sutton nathan.sutton at gmail.com
Mon Jan 28 18:26:44 EST 2008


awesome

Nathan Sutton
fowlduck at gmail.com
rspec 1.1
rspec_on_rails 1.1
rails 2.0.2

On Jan 28, 2008, at 5:24 PM, Jay Donnell wrote:

> I apologize, I oversimplified for the sake of brevity. We have most  
> of the models written but there are some pieces than aren't and  
> won't be written in the near future. I wanted to mock them out in  
> some form so we can implement those portions of the views. Things  
> like certain features of the sidebar, etc. I don't want to make  
> place holder methods in the actual models because they will be  
> worked on at some point and I want the views to continue working  
> until those pieces are complete.
>
> I guess I can use dummy methods in my models that simply return some  
> canned result. Maybe even name it 'my_method_dummy' so I can easily  
> track down the dummy methods. The stubbing syntax is so clean In  
> rspec that I was hoping I could define a bunch of mocks in a single  
> place, environment.rb maybe, and be able to easily glance to see  
> what is still being mocked. We also have different people working on  
> the views vs the models and would like for the views to progress  
> separately from the models. We can do this by spec'ing the views in  
> isolation but it would be nice to see the views integrated into a  
> functioning page as well.
>
>> you
> end
> up
> doing
> a
> lot
> of
> dev
> work
> before
> you
> find
> out
>> if
> the
> feature
> you've
> built
> is
> acceptable
> (that's
> where
> stories
> come
>> in
> as
> well,
> defining
> acceptance
> criteria).
>
> I've used my approach with success using flex and web services. I  
> created web services that returned canned data and developed the UI  
> in flex before developing the back-end. I feel this methods works  
> well and lead to less dev work because we didn't implement models  
> only to find out that we didn't really want it to work that way. We  
> fleshed out the way we wanted the site to work with a functioning  
> front-end before doing the heavy dev work on the back-end.
>
> jay
>
>> That's
> not
> really
> what
> mocks
> are
> for.
> Mocks
> are
> a
> testing
> tool
> that
>> help
> you
> discover
> the
> interactions
> between
> objects
> in
> your
> code.
> ...
>> It
> would
> probably
> be
> a
> bad
> idea
> to
> implement
> the
> site
> backed
> by
> mocks,
>> because
> you
> end
> up
> going
> top-down
> instead
> of
> outside-in.
> There's
> a
>> big
> difference.
> Top-down
> is
> implementing
> a
> layer
> for
> the
> entire
>> application,
> then
> moving
> to
> the
> layer
> it
> depends
> on,
> all
> the
> way
> down
>> until
> the
> app
> runs.
> The
> problem
> with
> that
> is
> that
> the
> feedback
> loop
>> is
> very
> wide,
> both
> in
> a
> development
> and
> business
> sense.
> In
> a
>> development
> sense,
> you
> don't
> really
> know
> that
> your
> app
> works
> until
> you
>> type
> that
> final
> character
> that
> brings
> the
> whole
> thing
> together.
> In
> a
>> business
> sense,
> you
> end
> up
> doing
> a
> lot
> of
> dev
> work
> before
> you
> find
> out
>> if
> the
> feature
> you've
> built
> is
> acceptable
> (that's
> where
> stories
> come
>> in
> as
> well,
> defining
> acceptance
> criteria).
>
>
>
>
>
>
>       
> ____________________________________________________________________________________
> Looking for last minute shopping deals?
> Find them fast with Yahoo! Search.  http://tools.search.yahoo.com/newsearch/category.php?category=shopping
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users



More information about the rspec-users mailing list