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 R.
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 R. [email protected]
wrote:

describe SomeResourcesController 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

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs