Rails - Apr 2006 - post() to other controller in functional test?

In a functional test, I want to call an action in another controller
(a login) before testing things in the current controller. As far as I
can tell from the extremely sparse documentation and the AWDR book,
this seems to be impossible. The post() functions takes an action
argument only, and that''s that. Surely I must be misunderstanding
things?
-- 
		     Calle Dybedahl <calle@cyberpomo.com>
		 http://www.livejournal.com/users/cdybedahl/
       "Then I dream of a world where idiots are hunted like wild
pigs"
		  -- Stephen Edwards, scary.devil.monastery

Calle Dybedahl wrote:
> In a functional test, I want to call an action in another controller
> (a login) before testing things in the current controller. As far as I
> can tell from the extremely sparse documentation and the AWDR book,
> this seems to be impossible. The post() functions takes an action
> argument only, and that''s that. Surely I must be misunderstanding
> things?

You have to set the @controller instance variable to the controller that 
should be used.

 From my test_helper function `login`

def login(user_name=''user'',
password=''12345'')
     # save the current controller
     old_controller = @controller

     # use the login controller
     @controller = LoginController.new

     # perform the actual login
     post :login, :user_login => user_name, :user_password => password
     assert_redirected_to :controller => ''welcome'', :action
=> ''index''

     #check his values in the session
     assert_not_nil session[:user]

     assert_equal session[:user], User.find_by_login(''user'')

     # restore the original controller
     @controller = old_controller
end

Jonathan


-- 
Jonathan Weiss
http://blog.innerewut.de

Hello Calle,
> In a functional test, I want to call an action in another controller
> (a login) before testing things in the current controller. As far as I
> can tell from the extremely sparse documentation and the AWDR book,
> this seems to be impossible. The post() functions takes an action
> argument only, and that''s that. Surely I must be misunderstanding
> things?
Have you checked Integration tests ?

http://jamis.jamisbuck.org/articles/2006/03/09/integration-testing-in-rails-1-1

http://api.rubyonrails.org/classes/ActionController/IntegrationTest.html

    -- Jean-Fran?ois.

--
? la renverse.

>>>>> "Jean-Fran?ois" == Jean-Fran?ois 
<jf.web3@gmail.com> writes:
> Have you checked Integration tests ?
>
http://jamis.jamisbuck.org/articles/2006/03/09/integration-testing-in-rails-1-1
> http://api.rubyonrails.org/classes/ActionController/IntegrationTest.html
No. I probably should. Thanks.
-- 
		     Calle Dybedahl <calle@cyberpomo.com>
		 http://www.livejournal.com/users/cdybedahl/
		"Let me answer that question with a headbutt."
		      -- Buffy, Buffy the Vampire Slayer

On Apr 23, 2006, at 10:22 AM, Calle Dybedahl wrote:
> In a functional test, I want to call an action in another controller
> (a login) before testing things in the current controller.
No, you don''t.  When testing you should test the smallest set of  
behavior possible.  By running through login you involve more code  
and make your tests slower.  Testing should be about rapid, accurate  
feedback.
> As far as I can tell from the extremely sparse documentation and  
> the AWDR book,
> this seems to be impossible. The post() functions takes an action
> argument only, and that''s that. Surely I must be misunderstanding
> things?
No, you''re not.

Instead write a util method that does whatever login does.  This  
removes the necessity of passing around the username and password to  
make the login work.  From one of my apps:

class RouteControllerTest < Test::Rails::ControllerTestCase

   fixtures :users, :routes, :points, :photos

   def test_delete
     util_login users(:herbert)
     get :delete, :id => routes(:work).id
     assert_response :success
     assert_assigned :action_title, "Deleting
\"#{routes(:work).name}\""
     assert_assigned :route, routes(:work)
   end

   def util_login(user)
     session[:user] = user
   end

end

-- 
Eric Hodel - drbrain@segment7.net - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant

http://trackmap.robotcoop.com

>>>>> "Eric" == Eric Hodel <drbrain@segment7.net>
writes:
> By running through login you involve more code and make your tests
> slower. Testing should be about rapid, accurate feedback.
You have a point in that it''s a good idea to test as little code as
possible, but the speed argument doesn''t hold water. Actually running
the tests (according to the printed timings) takes about 1/20th of the
total runtime of a plain "rake". Optimizing the tests themselves for
speed would be optimization in the wrong place.
> Instead write a util method that does whatever login does. 
That''s what I ended up doing. I still think it feels wrong, since the
method is not guaranteed to do what a real login does, and if I ever
change the login process I will have to adjust the same thing in more
than one place. That''s not very DRY.
> class RouteControllerTest < Test::Rails::ControllerTestCase
>    fixtures :users, :routes, :points, :photos
>    def test_delete
>      util_login users(:herbert)
[snip]
>    end
>    def util_login(user)
>      session[:user] = user
>    end
> end
Does that really work for you? when I try the same thing I get this:

  1) Error:
test_basic(ReadControllerTest):
TypeError: Symbol as array index
    ./test/functional/../test_helper.rb:18:in `[]=''
    ./test/functional/../test_helper.rb:18:in `util_login''
    ./test/functional/read_controller_test.rb:15:in `test_basic''

If I put a dummy get() of an existing action first, the login method
starts working just fine. 
-- 
		     Calle Dybedahl <calle@cyberpomo.com>
		 http://www.livejournal.com/users/cdybedahl/
     "If the number one item on the web is porn, number two has gotta be
		  complaining." -- robin_d_laws, LiveJournal

On 4/27/06, Calle Dybedahl <rails@cyberpomo.com>
wrote:
> >>>>> "Eric" == Eric Hodel
<drbrain@segment7.net> writes:
>
> > By running through login you involve more code and make your tests
> > slower. Testing should be about rapid, accurate feedback.
>
> You have a point in that it''s a good idea to test as little code
as
> possible, but the speed argument doesn''t hold water. Actually
running
> the tests (according to the printed timings) takes about 1/20th of the
> total runtime of a plain "rake". Optimizing the tests themselves
for
> speed would be optimization in the wrong place.
>
> > Instead write a util method that does whatever login does.
>
> That''s what I ended up doing. I still think it feels wrong, since
the
> method is not guaranteed to do what a real login does, and if I ever
> change the login process I will have to adjust the same thing in more
> than one place. That''s not very DRY.
>
> > class RouteControllerTest < Test::Rails::ControllerTestCase
>
> >    fixtures :users, :routes, :points, :photos
>
> >    def test_delete
> >      util_login users(:herbert)
> [snip]
> >    end
>
> >    def util_login(user)
> >      session[:user] = user
> >    end
>
> > end
>
> Does that really work for you? when I try the same thing I get this:
>
>   1) Error:
> test_basic(ReadControllerTest):
> TypeError: Symbol as array index
>     ./test/functional/../test_helper.rb:18:in `[]=''
>     ./test/functional/../test_helper.rb:18:in `util_login''
>     ./test/functional/read_controller_test.rb:15:in `test_basic''
>
> If I put a dummy get() of an existing action first, the login method
> starts working just fine.
> --
You need @request.session[:user] = user, rather than simple session[:user]

On Apr 27, 2006, at 5:57 AM, Wilson Bilkovich wrote:
> On 4/27/06, Calle Dybedahl <rails@cyberpomo.com> wrote:
>>> "Eric" == Eric Hodel <drbrain@segment7.net> writes:
>>>    def util_login(user)
>>>      session[:user] = user
>>>    end
>>
>>> end
>>
>> Does that really work for you? when I try the same thing I get this:
>>
>>   1) Error:
>> test_basic(ReadControllerTest):
>> TypeError: Symbol as array index
>>     ./test/functional/../test_helper.rb:18:in `[]=''
>>     ./test/functional/../test_helper.rb:18:in `util_login''
>>     ./test/functional/read_controller_test.rb:15:in
`test_basic''
>>
>> If I put a dummy get() of an existing action first, the login method
>> starts working just fine.
>> --
>
> You need @request.session[:user] = user, rather than simple session 
> [:user]
I wrote Test::Rails which is part of ZenTest to fix this violation of  
DRY (and because sessions not working before a request is just silly).

-- 
Eric Hodel - drbrain@segment7.net - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant

http://trackmap.robotcoop.com

On Apr 27, 2006, at 3:19 AM, Calle Dybedahl wrote:
>>>>>> "Eric" == Eric Hodel
<drbrain@segment7.net> writes:
>
>> By running through login you involve more code and make your tests
>> slower. Testing should be about rapid, accurate feedback.
>
> You have a point in that it''s a good idea to test as little code
as
> possible, but the speed argument doesn''t hold water. Actually
running
> the tests (according to the printed timings) takes about 1/20th of the
> total runtime of a plain "rake". Optimizing the tests themselves
for
> speed would be optimization in the wrong place.
Running tests under rake is too slow.  I need constant, immediate  
feedback so I wrote autotest and ruby_fork to get it.
>> Instead write a util method that does whatever login does.
>
> That''s what I ended up doing. I still think it feels wrong, since
the
> method is not guaranteed to do what a real login does, and if I ever
> change the login process I will have to adjust the same thing in more
> than one place. That''s not very DRY.
a) I''ve never had that happen.
b) When you write your tests this way you are no longer unit testing.
>> class RouteControllerTest < Test::Rails::ControllerTestCase
>
>>    fixtures :users, :routes, :points, :photos
>
>>    def test_delete
>>      util_login users(:herbert)
> [snip]
>>    end
>
>>    def util_login(user)
>>      session[:user] = user
>>    end
>
>> end
>
> Does that really work for you? when I try the same thing I get this:
>
>   1) Error:
> test_basic(ReadControllerTest):
> TypeError: Symbol as array index
>     ./test/functional/../test_helper.rb:18:in `[]=''
>     ./test/functional/../test_helper.rb:18:in `util_login''
>     ./test/functional/read_controller_test.rb:15:in `test_basic''
>
> If I put a dummy get() of an existing action first, the login method
> starts working just fine.
Install ZenTest, switch to Test::Rails.

-- 
Eric Hodel - drbrain@segment7.net - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant

http://trackmap.robotcoop.com

For an application I am working on, I have to allow user submitted  
HTML (via TinyMCE). I only want to allow a tiny subset of the HTML  
specification. I tried to find a function that would be able to strip  
away the unwanted HTML tags, attributes, and styles that were  
submitted, but didn''t find one. So, I wrote a function myself.

The parameter format is similar to TinyMCE''s valid_elements, but  
differs in that 1) it offers a lot less and 2) I wasn''t exactly 100%  
sure about what each bit of the valid_elements in TinyMCE''s  
documentation did.

However, being a ruby newbie, I thought I would post what I came up  
with here for feedback and comments on improving my "rubyisms". As of
now, it''s still pretty limited, but suits my minimum needs. I  
probably will expand on it in the future, maybe convert it to a Rails  
plugin.

And I also included a quick unit test (although I still need to  
expand on it)

http://www.conqueredthe.us/personal/html_sanitize.zip

Comments please.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060429/430c114d/attachment.html

You''d probably get more comments if you didn''t thread hijack.

b

Carl Lerche wrote:
> For an application I am working on, I have to allow user submitted HTML 
> (via TinyMCE). I only want to allow a tiny subset of the HTML 
> specification. I tried to find a function that would be able to strip 
> away the unwanted HTML tags, attributes, and styles that were submitted, 
> but didn''t find one. So, I wrote a function myself.
> 
> The parameter format is similar to TinyMCE''s valid_elements, but
differs
> in that 1) it offers a lot less and 2) I wasn''t exactly 100% sure
about
> what each bit of the valid_elements in TinyMCE''s documentation
did.
> 
> However, being a ruby newbie, I thought I would post what I came up with 
> here for feedback and comments on improving my "rubyisms". As of
now,
> it''s still pretty limited, but suits my minimum needs. I probably
will
> expand on it in the future, maybe convert it to a Rails plugin.
> 
> And I also included a quick unit test (although I still need to expand 
> on it)
> 
> http://www.conqueredthe.us/personal/html_sanitize.zip
> 
> Comments please.
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails

I see... I wasn''t aware that I was thread hijacking. I apologize.

-carl
On Apr 30, 2006, at 9:42 AM, Ben Munat wrote:
> You''d probably get more comments if you didn''t thread
hijack.
>
> b
>
> Carl Lerche wrote:
>> For an application I am working on, I have to allow user submitted  
>> HTML (via TinyMCE). I only want to allow a tiny subset of the HTML  
>> specification. I tried to find a function that would be able to  
>> strip away the unwanted HTML tags, attributes, and styles that  
>> were submitted, but didn''t find one. So, I wrote a function
myself.
>> The parameter format is similar to TinyMCE''s valid_elements,
but
>> differs in that 1) it offers a lot less and 2) I wasn''t
exactly
>> 100% sure about what each bit of the valid_elements in
TinyMCE''s
>> documentation did.
>> However, being a ruby newbie, I thought I would post what I came  
>> up with here for feedback and comments on improving my
"rubyisms".
>> As of now, it''s still pretty limited, but suits my minimum
needs.
>> I probably will expand on it in the future, maybe convert it to a  
>> Rails plugin.
>> And I also included a quick unit test (although I still need to  
>> expand on it)
>> http://www.conqueredthe.us/personal/html_sanitize.zip
>> Comments please.
>> --------------------------------------------------------------------- 
>> ---
>> _______________________________________________
>> Rails mailing list
>> Rails@lists.rubyonrails.org
>> http://lists.rubyonrails.org/mailman/listinfo/rails
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails

And I apologize if I sounded snotty or if you don''t understand what
I''m talking about. To
my mail reader, it appears that you posted your email by hitting "reply
to" on someone
else''s mail, deleting the subject and content, typing in your stuff --
your new thread --
and hitting send.

Doing this sets a mail header saying that your email is a reply to an email that
it''s not
a reply to. And a threaded mail reader will look at these headers and collapse
everything
that says it''s a reply to another email into a threaded list.

On a list with as much volume as this one, it''s very likely that a lot
of people leave all
the threads collapsed and just scan the subjects... of the emails that started
the thread,
that is. So, if you start a thread by replying to an email in a different
thread, then
your email is hidden as a reply to something it''s not a reply to!
Making it less likely to
be seen.

Anyway, if that''s not what you did then, well, that''s weird...
I don''t know how else a
completely unrelated email gets an "In-reply-to:..." header in it. If
it is what you did,
don''t sweat it... just live and learn.

b


Carl Lerche wrote:
> I see... I wasn''t aware that I was thread hijacking. I apologize.
> 
> -carl
> On Apr 30, 2006, at 9:42 AM, Ben Munat wrote:
> 
>> You''d probably get more comments if you didn''t thread
hijack.
>>
>> b
>>
>> Carl Lerche wrote:
>>
>>> For an application I am working on, I have to allow user submitted
>>> HTML (via TinyMCE). I only want to allow a tiny subset of the HTML
>>> specification. I tried to find a function that would be able to  
>>> strip away the unwanted HTML tags, attributes, and styles that 
were
>>> submitted, but didn''t find one. So, I wrote a function
myself.
>>> The parameter format is similar to TinyMCE''s
valid_elements, but
>>> differs in that 1) it offers a lot less and 2) I wasn''t
exactly  100%
>>> sure about what each bit of the valid_elements in
TinyMCE''s
>>> documentation did.
>>> However, being a ruby newbie, I thought I would post what I came 
up
>>> with here for feedback and comments on improving my
"rubyisms".  As
>>> of now, it''s still pretty limited, but suits my minimum
needs.  I
>>> probably will expand on it in the future, maybe convert it to a  
>>> Rails plugin.
>>> And I also included a quick unit test (although I still need to  
>>> expand on it)
>>> http://www.conqueredthe.us/personal/html_sanitize.zip
>>> Comments please.
>>>
---------------------------------------------------------------------
>>> ---
>>> _______________________________________________
>>> Rails mailing list
>>> Rails@lists.rubyonrails.org
>>> http://lists.rubyonrails.org/mailman/listinfo/rails
>>
>> _______________________________________________
>> Rails mailing list
>> Rails@lists.rubyonrails.org
>> http://lists.rubyonrails.org/mailman/listinfo/rails
> 
> 
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails

Carl,

This happens all the time, don''t worry about it. As you may have  
deduced from Ben''s explanation, what you should do in this situation  
is repost your original message so that it starts a new thread. I  
read this list exactly as Ben describes so I didn''t see your original  
post (though I did see the post about thread hijacking :-). And since  
I''m facing a very similar situation I''d be one of the people
likely
to respond.

Thread hijacking is awfully easy to do, and I swear that some mail  
readers are way too smart for their own good and try to ''help''
a
little too much (and you wind up unintentionally hijacking a thread).

BTW, you might be asking yourself why a change of subject doesn''t  
automatically start a new thread. Well, it is also considered good  
practice to change the subject within a long thread to indicate a  
focusing of the subject but that is clearly still in the original  
thread. So, we either get the occasional hijacked thread, or the  
frequent fragmentation of a thread.

Cheers,
Bob

On Apr 30, 2006, at 11:51 PM, Ben Munat wrote:
> And I apologize if I sounded snotty or if you don''t understand
what
> I''m talking about. To my mail reader, it appears that you posted  
> your email by hitting "reply to" on someone else''s mail,
deleting
> the subject and content, typing in your stuff -- your new thread --  
> and hitting send.
>
> Doing this sets a mail header saying that your email is a reply to  
> an email that it''s not a reply to. And a threaded mail reader will
> look at these headers and collapse everything that says it''s a  
> reply to another email into a threaded list.
>
> On a list with as much volume as this one, it''s very likely that a
> lot of people leave all the threads collapsed and just scan the  
> subjects... of the emails that started the thread, that is. So, if  
> you start a thread by replying to an email in a different thread,  
> then your email is hidden as a reply to something it''s not a reply
> to! Making it less likely to be seen.
>
> Anyway, if that''s not what you did then, well, that''s
weird... I
> don''t know how else a completely unrelated email gets an
"In-reply-
> to:..." header in it. If it is what you did, don''t sweat
it... just
> live and learn.
>
> b
>
>
> Carl Lerche wrote:
>> I see... I wasn''t aware that I was thread hijacking. I
apologize.
>> -carl
>> On Apr 30, 2006, at 9:42 AM, Ben Munat wrote:
>>> You''d probably get more comments if you didn''t
thread hijack.
>>>
>>> b
>>>
>>> Carl Lerche wrote:
>>>
>>>> For an application I am working on, I have to allow user  
>>>> submitted  HTML (via TinyMCE). I only want to allow a tiny  
>>>> subset of the HTML  specification. I tried to find a function  
>>>> that would be able to  strip away the unwanted HTML tags,  
>>>> attributes, and styles that  were submitted, but
didn''t find
>>>> one. So, I wrote a function myself.
>>>> The parameter format is similar to TinyMCE''s
valid_elements,
>>>> but  differs in that 1) it offers a lot less and 2) I
wasn''t
>>>> exactly  100% sure about what each bit of the valid_elements in
>>>> TinyMCE''s  documentation did.
>>>> However, being a ruby newbie, I thought I would post what I  
>>>> came  up with here for feedback and comments on improving my  
>>>> "rubyisms".  As of now, it''s still pretty
limited, but suits my
>>>> minimum needs.  I probably will expand on it in the future,  
>>>> maybe convert it to a  Rails plugin.
>>>> And I also included a quick unit test (although I still need to
>>>> expand on it)
>>>> http://www.conqueredthe.us/personal/html_sanitize.zip
>>>> Comments please.
>>>>
-------------------------------------------------------------------
>>>> -- ---
>>>> _______________________________________________
>>>> Rails mailing list
>>>> Rails@lists.rubyonrails.org
>>>> http://lists.rubyonrails.org/mailman/listinfo/rails
>>>
>>> _______________________________________________
>>> Rails mailing list
>>> Rails@lists.rubyonrails.org
>>> http://lists.rubyonrails.org/mailman/listinfo/rails
>> _______________________________________________
>> Rails mailing list
>> Rails@lists.rubyonrails.org
>> http://lists.rubyonrails.org/mailman/listinfo/rails
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
----
Bob Hutchison                  -- blogs at <http://www.recursive.ca/ 
hutch/>
Recursive Design Inc.          -- <http://www.recursive.ca/>
Raconteur                      -- <http://www.raconteur.info/>
xampl for Ruby                 -- <http://rubyforge.org/projects/xampl/>