Re: client first, top down, outside in, etc with rails

Testing RSpec
1

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

2

awesome

Nathan S.
[email protected]
rspec 1.1
rspec_on_rails 1.1
rails 2.0.2

3

On Jan 28, 2008 3:24 PM, Jay D. [email protected] 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 :slight_smile: 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 :slight_smile:

Pat

4

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:

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