rspec users - Jan 2008 - client first, top down, outside in, etc with rails

I''m starting a new project and I want to try writing the client first.
I.e. I want to write my ''views'' first and I would like to mock
out all the models in such a way that I can run the site and browse it with the
mocked out models. Is it easy to use rspec''s mocking for this sort of
thing and has anyone done it before? Does anyone know of a tutorial out there
for doing something like this?




     
____________________________________________________________________________________
Looking for last minute shopping deals?  
Find them fast with Yahoo! Search. 
http://tools.search.yahoo.com/newsearch/category.php?category=shopping

On Jan 28, 2008 12:01 PM, Jay Donnell <jaydonnell at yahoo.com>
wrote:
> I''m starting a new project and I want to try writing the client
first. I.e. I want to write my ''views'' first and I would like
to mock out all the models in such a way that I can run the site and browse it
with the mocked out models. Is it easy to use rspec''s mocking for this
sort of thing and has anyone done it before? Does anyone know of a tutorial out
there for doing something like this?
That''s not really what mocks are for.  Mocks are a testing tool that
help you discover the interactions between objects in your code.

I''d say the best way is to develop in small iterations.  Write a story
that represents a very small, but useful bit of functionality.
Implement it, going outside-in, and then when the story is completed
you''ve got something.  Then work on the next story.

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).

It *is* a good idea to sometimes work on the interaction flow before
writing a bunch of Rails code, but that should really be done with
plain HTML wireframes, no application coding.

Pat

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

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

sorry about that, I have no idea how that happened. It looked fine in yahoo mail
before I sent it :/





     
____________________________________________________________________________________
Looking for last minute shopping deals?  
Find them fast with Yahoo! Search. 
http://tools.search.yahoo.com/newsearch/category.php?category=shopping

On Jan 28, 2008 3:24 PM, Jay Donnell <jaydonnell at yahoo.com>
wrote:
> 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.
hrm...well if you want it all in one place, I''d stick it in some
mocked_methods.rb file and require that.  You can open the classes you
want there

User.class_eval do
  def full_name
    "Johnny Tsunami"
  end
end

That way it''s easy to see where they all are.  You really
don''t need
to introduce RSpec dependencies into your production code.  Just
define methods on the class you want, or use OpenStruct and return
canned values, or write your own simple stub class.  If I was doing
this a bunch (I never would, of course :) then I might write a macro
that defines these stubs for me and includes some diagnostic info,
like a logger.warn("*** dude this is a stubbed method ***") and maybe
the caller information as well.  Then I could just do

User.stub_method(:full_name, "Johnny Tsunami")

Going that route would let you collect info about how many times
they''re called, blah blah blah.

Or you could just implement your code :)

Pat

Another approach to what Pat mentioned is would be to use a presenter
approach. We use presenters to encapsulate view logic and they often
hide (or delegate) functionality to one or more models based on the UI
component you''re focusing on.

This route doesn''t muck up your models with things that may come in
the future. When they do come you can refactor your presenter to
delegate to your model, when and if your model is the object that is
going to do the job. Right now it''s all view implementation anyways
and the way we use presenters encapsulate the requirements of the
view.

Here''s some info on how we use presenters:
http://spin.atomicobject.com/2008/01/27/the-exceptional-presenter/

The way we use presenter''s is different then Jay Fields, so if you
think you know what a presenter is and how to use them based on Jay
Fields talks or blogs, then you should really read the above as its a
different take on presenters with different goals in mind.

Zach



On Jan 29, 2008 1:34 AM, Pat Maddox <pergesu at gmail.com>
wrote:
> On Jan 28, 2008 3:24 PM, Jay Donnell <jaydonnell at yahoo.com> wrote:
> > 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.
>
> hrm...well if you want it all in one place, I''d stick it in some
> mocked_methods.rb file and require that.  You can open the classes you
> want there
>
> User.class_eval do
>   def full_name
>     "Johnny Tsunami"
>   end
> end
>
> That way it''s easy to see where they all are.  You really
don''t need
> to introduce RSpec dependencies into your production code.  Just
> define methods on the class you want, or use OpenStruct and return
> canned values, or write your own simple stub class.  If I was doing
> this a bunch (I never would, of course :) then I might write a macro
> that defines these stubs for me and includes some diagnostic info,
> like a logger.warn("*** dude this is a stubbed method ***") and
maybe
> the caller information as well.  Then I could just do
>
> User.stub_method(:full_name, "Johnny Tsunami")
>
> Going that route would let you collect info about how many times
> they''re called, blah blah blah.
>
> Or you could just implement your code :)
>
> Pat
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>


-- 
Zach Dennis
http://www.continuousthinking.com