On Wed, Jan 14, 2009 at 7:30 PM, David Chelimsky <[email protected]>wrote:
> On Wed, Jan 14, 2009 at 8:23 PM, Chris Kampmeier <[email protected]> > wrote: > > > (Or, here's a syntax-highlighted pastie: http://pastie.org/361114) > > Don't forget that the spec should come first :) Also, you're spec'ing > behaviour, not implementation. So for me, what you've got is this: > > specification: response.should redirect_to("/") > behaviour: response.should redirect_to("/") > Thanks, definitely helpful. I think the main thing I needed to get in my head is that testing Rails controllers with rspec-rails is more about "behavior," unlike a typical unit-style, in that you're really testing the whole controller stack, and not just an isolated method. It's a little more high-level, since you really need the whole setup (request, response, etc.) to get anything done. > > Anyway, what should I really be doing here? I could use shared examples > to > > maintain DRY (it_should_behave_like :access_denied); > > > Personally, I've grown weary of it_should_behave_like. I'd write a > macro so you could say something like: > > describe PostsController do > context "handling DELETE /posts/2" do > denies_access_when "the post isn't destroyable by the current user" do > post = mock_model(Post, :destroyable_by? => false) > Post.stub!(:find).and_return(post) > post.should_not_receive(:destroy) > end > end > end Ooh, that's interesting. I see how you would implement that, but I'd never thought of using a "macro" block helper like that, myself. More generally, could you post a bit on why you've stopped using shared examples, and what it is about the syntax above that resonates with you? Looking at the two alternatives, it_should_behave_like seems like a more natural approach to me--it seems very declarative, and clear--but that might just be because I'm used to it. Thanks again! Chris Kampmeier
_______________________________________________ rspec-users mailing list [email protected] http://rubyforge.org/mailman/listinfo/rspec-users
