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@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
