Re: params not available for controller specs?

I get what you’re saying, but I was trying to fix a bug in existing
code in Substruct (that I did not write) that was caused by Rails
passing the array as a /-delimited string and then not automatically
decoding that string. As Substruct does not say that Edge Rails is a
requirement, I felt it was worth documenting what I had to change to run
it on Rails 1.2.x. Every code change should be driven by a test or
example; perhaps in this situation I should’ve gone over to Test::Unit
instead of staying in RSpec? An interesting philosophical thought…

Al

----- Original Message ----
From: Jarkko L. [email protected]
To: rspec-users [email protected]
Sent: Tuesday, December 4, 2007 10:09:01 AM
Subject: Re: [rspec-users] params not available for controller specs?

On 4.12.2007, at 18.19, Al Chou wrote:

Going back to my original message, I have the following at the
beginning of the download method:

def download
@orders = Order.find( params[:ids] )

The problem is that params[:ids], although built as an Array object
by the view that calls the download method on the controller, is
passed as a /-delimited string of id values.

If I set

<%= link_to “Test”, :controller => “clients”, :foo => [1, 2, 3, 4,
5] %>

I get this as the url:

http://localhost:3000/en/clients?foo[]=1&foo[]=2&foo[]=3&foo[]=4&foo[]=5

That will get correctly parsed back to an array in the receiving
action:

Parameters: {“action”=>“index”, “foo”=>[“1”, “2”, “3”, “4”, “5”],
“controller”=>“clients”, “locale”=>“en”}

This is Edge Rails, though, so YMMV.

Order.find() will not do the desired thing with that string, which

was intended to be an array by the view, but Rails passed it in a
string representation. So the method really should be

def download
@orders = Order.find( params[:ids].split( ‘/’ ) )

and what I’m trying to spec is the addition of the call to split().

IMHO there’s no need to stub string methods like that. Just do
something like this:

Order.should_receive(:find).with(%w(1 2
3)).and_return(@some_order_objects)

If params[:ids] is “1/2/3”, you can be pretty certain that split(“/”)
will work correctly so you’re more interested in that the find method
gets called with correct set of attributes, an array. It’s not really
interesting how that array got to be. In this case, you might notice
that somehow params[:ids] is an array after all and you can take the
split call away, and the spec will still pass.

I guess what I’m trying to say is that the split call is part of the
controller action’s internal implementation, and you should be
spec’ing how it behaves related to its surrounding world: fetches
stuff from the business model, assigns objects for the view etc.

//jarkko


Jarkko L.

http://www.railsecommerce.com
http://odesign.fi


rspec-users mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/rspec-users

  ____________________________________________________________________________________

Be a better sports nut! Let your teams follow you
with Yahoo Mobile. Try it now.
http://mobile.yahoo.com/sports;_ylt=At9_qDKvtAbMuh1G1SQtBI7ntAcJ

On Dec 4, 2007 2:09 PM, Al Chou [email protected] wrote:

I get what you’re saying, but I was trying to fix a bug in existing code in
Substruct (that I did not write) that was caused by Rails passing the array
as a /-delimited string and then not automatically decoding that string. As
Substruct does not say that Edge Rails is a requirement, I felt it was worth
documenting what I had to change to run it on Rails 1.2.x. Every code
change should be driven by a test or example; perhaps in this situation I
should’ve gone over to Test::Unit instead of staying in RSpec? An
interesting philosophical thought…

Seems to me this thread has been about how to deal with rails. I don’t
see what that has to do w/ a T::U vs rspec decision.