[rspec-users] should_redirect_to in advance - feels unnatural

David Chelimsky dchelimsky at gmail.com
Tue Nov 7 15:02:50 EST 2006

On 11/7/06, Jay Levitt <lists-rspec at shopwatch.org> wrote:
> I can understand that it's easier for rspec to set up a mock in advance
> of the controller call.

This was a philosophical choice, not a cop-out to make it easier to
implement. That sounds more defensive than it is meant to be. I just
want to assure you that our goal is to create the right API.

> But it makes it difficult to do something like:
> context "The HarkController, given Louie the logged-in user" do
>   setup do
>     post :login, :username => 'louie', :password => 'atest'
>   end
>   specify "should redirect Louie to the home page"...
>   specify "should set Louie to be the current user"...
> end
> Instead, I have to break out the should-redirect into its own call,
> since the post is done at setup time, but that's not an appropriate
> place for a spec.

The BDD way, at least as I see it, is rooted in the TDD way:

1. setup objects in a known starting state (setup - perhaps stubs)
2. set expectations of how the object should react to an action (mocks)
3. perform the action
4. verify that the object reacted as expected (verify mocks plus
additional assert-like expectations)

The setup/specify structure is intended to let you step 1 (setup) in
the setup and do whatever combination of 2-4 that you like in specify.
In my view, the post is the action, and it belongs in the specify
block in this case.

The problem there is that it doesn't feel DRY. That's a problem I'm
interested in solving, but I'd prefer to do it in a way that helps to
express the behaviour-driven nature of BDD. What that means yet I'm
not sure. I have a couple of ideas that I'll share as they become
slightly more fully baked. I'd love to hear yours in the mean time.

What I'm doing for examples like yours above is adding a method for
the post and calling it from each of my specify blocks. Still not
completely DRY, but it tells the story. And that is much more
important to me than the risk of having to change something in more
than one place in a spec.

As for before or after the action, we did add
controller.should_have_rendered for after. We could do something
similar: controller.should_have_redirected_to. Or we could do what I
originally had in there which was that should_render was smart enough
to work on either side of the action. Looking at a few specs, I found
that to be more confusing and, hence, split into 'before' and 'after'

Of these options, what do you like, and what not?

Thanks for playing,

> What's the right solution?
> Jay Levitt
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

More information about the rspec-users mailing list