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