On Sat, Mar 15, 2008 at 2:38 PM, Ben Mabey <[EMAIL PROTECTED]> wrote:

>  I am interested why having this approach has motivated you to take more
>  of a state based approach on testing controllers.
>  Assuming that you have other integration tests (stories) that test the
>  full stack then having the controller specs hit the DB doesn't seem to
>  buy you much and will slow your tests down quite a bit as compared to
>  the interaction-based approach.  I know you know this already so I am
>  trying to understand how this newer way of writing controllers is more
>  suited for allowing the specs to hit the db.  Skinny controllers have
>  been common practice for quite a while so I don't see how the layer of
>  abstraction of declaring actions like above really changes things on the
>  testing level.  Do you feel that interaction-based specs on the
>  controllers are too brittle.. or verbose.. or what?

At work where we're doing this, we don't use stories.  So our
controller specs act as the integration tests.  I think if we were
using stories, we likely wouldn't have controller tests at all.  Not
too sure about that though.

Another major reason for not using interaction-based tests is that all
of the controllers are identical, so any specs we write are just
testing framework code.  No sense in that.

Pat
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users

Reply via email to