I’m heading out of town, but had a quick thought I wanted to share.
Rather then using ambiguous named request helpers in controller specs
like “do_request”, I’ve been using more readable helpers like
“post_create”.
For example…
describe ProjectController do
def post_create
post :create, …
end
before do
end
it “creates a new project” do
Project.should_receive(:create).with(…)
post_create
end
end
IMO is adds a little more readability when looking at an individual
“it” behavior on a controller spec. We’ve been keeping the request
helpers as the first things immediately following a controller
specification, ie: “describe SomeController do”.
Thoughts?
I’ve always used do_post/do_put etc. But your way is perfectly
acceptable 
Pat
On Sat, 08 Mar 2008 15:51:01 -0500, Zach D. wrote:
I’m heading out of town, but had a quick thought I wanted to share.
Rather then using ambiguous named request helpers in controller specs
like “do_request”, I’ve been using more readable helpers like
“post_create”.
snip
IMO is adds a little more readability when looking at an individual “it”
behavior on a controller spec. We’ve been keeping the request helpers as
the first things immediately following a controller specification, ie:
“describe SomeController do”.
Thoughts?
I would agree on the readability. The reason I stay with it though is
that I have some shared behaviors that need to make the call on their
own. It seems like it would be somewhat less convenient to wrap up or
alias whatever method was performing a given HTTP verb.
On Sat, Mar 8, 2008 at 8:51 PM, Zach D. [email protected]
wrote:
end
IMO is adds a little more readability when looking at an individual
“it” behavior on a controller spec. We’ve been keeping the request
helpers as the first things immediately following a controller
specification, ie: “describe SomeController do”.
Thoughts?
Seems reasonable to me.
On Sat, Mar 8, 2008 at 11:06 PM, Pat M. [email protected] wrote:
I’ve always used do_post/do_put etc. But your way is perfectly acceptable 
That’s what I do too - but I like Zach’s idea here. Do you guys think
the generated examples should use this?
David
What about overriding method_missing in the shared example group that
will
make conversions:
post_XXXX → post :XXXX
put_XXXX → put :XXXX
etc.
David posted thoughts on the before/after stuff, which is similar to
what I
do :
http://blog.davidchelimsky.net/articles/2007/11/06/before_action-after_action
I do like having the before/after part, too, as it is nice to pass a
block
in occasionally.
-Corey
On Sun, Mar 9, 2008 at 6:46 AM, David C. [email protected]
On Sun, Mar 9, 2008 at 3:31 PM, Corey H. [email protected]
wrote:
What about overriding method_missing in the shared example group that will
make conversions:
post_XXXX → post :XXXX
put_XXXX → put :XXXX
That’s fine until you start adding parameters, at which point you’d
end up calling this:
put_update :id => 3
I don’t see much point in that
Cheers,
David
On Sun, Mar 9, 2008 at 4:46 AM, David C. [email protected]
wrote:
On Sat, Mar 8, 2008 at 11:06 PM, Pat M. [email protected] wrote:
I’ve always used do_post/do_put etc. But your way is perfectly acceptable
That’s what I do too - but I like Zach’s idea here. Do you guys think
the generated examples should use this?
I’m indifferent to it. The reason I use do_put instead of put_update
is because when dealing with resources, the interface is PUT
/resource. The fact that it maps to the #update method is a Rails
implementation detail. So I find it useful to name that little helper
method in a way that reflects the external API.
That’s just the way I think of it though. I’d be pissed off if
someone did a global search and replace on my code, but for RSpec
generated code I don’t have a strong opinion. I think it raises an
interesting philosophical issue though. We care about naming a great
deal, so do_request->post_create is certainly an improvement. And for
me, do_post is better than post_create, because my apps are all
RESTful. So the question in my mind is whether our suggestion ends at
better naming, or if we ought to subtly encourage more RESTful apps,
which seems to be a widespread good practice in the Rails community.
I’m also afraid that this is a bike shed scenario and I’m thinking way
too deeply into it. Someone please show me the light
Pat