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

Zach Dennis zach.dennis at gmail.com
Tue Jan 29 08:51:46 EST 2008

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

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.


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

More information about the rspec-users mailing list