rspec users - Dec 2011 - Difference between "get '/path/'" and "get :symbol"?

What''s the difference between these two forms, in a spec file?

 get ''/prefix/resources'' # get index of resources
 get :index              # get index of resources

I have some tests that work one way, some that work the other way, and seems
like none work any way but the way they''re presently written. But
I''m perilously close to having to try a form at random until I find
which one works!

A bit more specifically,

In spec/controllers/some_resource_controller_spec.rb, I
have
> describe SomeResourcesController do
>   describe "some behavior" do
>     it "should return index of SomeResources" do
>       get :index
(Using the path form here results in ''No route matches
{:controller=>"some_resources",
:action="/some_resources"}'')

But in spec/integration/some_others_resource_spec.rb, I
have
> describe "some other resource" do
>   describe "GET /some_others"
>     it "should return index of SomeOthers" do
>       get "/some_others"
(Using the symbol form here results in ''bad argument(expected URI
object or URI string)''.)

Is it the difference between living in controllers/ vs. integration/ that
determines the get form? Or the difference in whether I name the class in the
outermost "describe"? Something else? Some combination?


-==-
Jack Repenning
Technologist
CollabNet Cloud Services
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
office: +1 650.228.2562
twitter: http://twitter.com/jrep

On Wed, Dec 14, 2011 at 1:13 PM, Jack Repenning <jrepenning at collab.net>
wrote:
> What''s the difference between these two forms, in a spec file?
>
> ?get ''/prefix/resources'' # get index of resources
> ?get :index ? ? ? ? ? ? ?# get index of resources
>
> I have some tests that work one way, some that work the other way, and
seems like none work any way but the way they''re presently written. But
I''m perilously close to having to try a form at random until I find
which one works!
>
> A bit more specifically,
>
> In spec/controllers/some_resource_controller_spec.rb, I have
>> describe SomeResourcesController do
>> ? describe "some behavior" do
>> ? ? it "should return index of SomeResources" do
>> ? ? ? get :index
>
> (Using the path form here results in ''No route matches
{:controller=>"some_resources",
:action="/some_resources"}'')
>
> But in spec/integration/some_others_resource_spec.rb, I have
>> describe "some other resource" do
>> ? describe "GET /some_others"
>> ? ? it "should return index of SomeOthers" do
>> ? ? ? get "/some_others"
>
> (Using the symbol form here results in ''bad argument(expected URI
object or URI string)''.)
>
> Is it the difference between living in controllers/ vs. integration/ that
determines the get form?
Yes. Integration specs are built on top of Rails integration tests,
which are not bound to any one controller, and therefore require the
full path that you would use in the browser.

Controller specs are built on top of Rails functional tests (which are
now implemented in ActionController::TestCase, so they may as well be
called controller tests), which are controller aware.

I think the confusion is that we type "get" for both, but
we''re
simulating an http get in integration specs, whereas we''re doing
something closer to directly invoking an action on a controller in
controller specs. A new method for controller specs, like "invoke"
might clear the air, but I think we''re all so accustomed to using the
"get/post/put/delete" abstractions (leaky though they are in this
case), that most users would not support a change like that. Also,
controller specs _do_ care about the http verb, even though the action
is being invoked (almost) directly. This is probably not necessary to
serve the purpose of a controller, but Rails has always blurred the
lines between what is routing and what is controller, so trying to
impose a cleaner separation between them would be hard to stomach for
many Rails users.

And so here we are!

FWIW - I have the same problems managing RSpec. There are a lot of
things I''d like to rip out, but doing so would be more disruptive than
helpful, even though they might lead to a cleaner simpler model.

HTH,
David

> Or the difference in whether I name the class in the outermost
"describe"? Something else? Some combination?