Forum: Ruby on Rails post() to other controller in functional test?

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Calle D. (Guest)
on 2006-04-23 21:31
(Received via mailing list)
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 D. <removed_email_address@domain.invalid>
		 http://www.livejournal.com/users/cdybedahl/
       "Then I dream of a world where idiots are hunted like wild pigs"
		  -- Stephen Edwards, scary.devil.monastery
Jonathan W. (Guest)
on 2006-04-23 22:25
(Received via mailing list)
Calle D. 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
Jean-François (Guest)
on 2006-04-23 22:28
(Received via mailing list)
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/int...

http://api.rubyonrails.org/classes/ActionControlle...

    -- Jean-François.
Calle D. (Guest)
on 2006-04-25 11:08
(Received via mailing list)
>>>>> "Jean-François" == Jean-François  <removed_email_address@domain.invalid> writes:

> Have you checked Integration tests ?

> http://jamis.jamisbuck.org/articles/2006/03/09/int...
> http://api.rubyonrails.org/classes/ActionControlle...

No. I probably should. Thanks.
--
		     Calle D. <removed_email_address@domain.invalid>
		 http://www.livejournal.com/users/cdybedahl/
		"Let me answer that question with a headbutt."
		      -- Buffy, Buffy the Vampire Slayer
Eric H. (Guest)
on 2006-04-26 22:36
(Received via mailing list)
On Apr 23, 2006, at 10:22 AM, Calle D. 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 H. - removed_email_address@domain.invalid - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant

http://trackmap.robotcoop.com
Calle D. (Guest)
on 2006-04-27 14:20
(Received via mailing list)
>>>>> "Eric" == Eric H. <removed_email_address@domain.invalid> 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 D. <removed_email_address@domain.invalid>
		 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
Wilson B. (Guest)
on 2006-04-27 16:57
(Received via mailing list)
On 4/27/06, Calle D. <removed_email_address@domain.invalid> wrote:
>
>
>
> starts working just fine.
> --

You need @request.session[:user] = user, rather than simple
session[:user]
Eric H. (Guest)
on 2006-05-03 21:09
(Received via mailing list)
On Apr 27, 2006, at 5:57 AM, Wilson B. wrote:

>>   1) Error:
> 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 H. - removed_email_address@domain.invalid - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant

http://trackmap.robotcoop.com
Eric H. (Guest)
on 2006-05-03 21:09
(Received via mailing list)
On Apr 27, 2006, at 3:19 AM, Calle D. wrote:

>>>>>> "Eric" == Eric H. <removed_email_address@domain.invalid> 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.

>>      session[:user] = user
>     ./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 H. - removed_email_address@domain.invalid - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant

http://trackmap.robotcoop.com
Carl L. (Guest)
on 2006-05-03 21:09
(Received via mailing list)
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.
Ben M. (Guest)
on 2006-08-03 15:33
(Received via mailing list)
You'd probably get more comments if you didn't thread hijack.

b
Carl L. (Guest)
on 2006-08-03 16:22
(Received via mailing list)
I see... I wasn't aware that I was thread hijacking. I apologize.

-carl
Ben M. (Guest)
on 2006-08-03 16:22
(Received via mailing list)
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
Bob H. (Guest)
on 2006-08-03 16:22
(Received via mailing list)
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 M. wrote:

>
> live and learn.
>>> b
>>>> but  differs in that 1) it offers a lot less and 2) I wasn't
>>>> Comments please.
>>> http://lists.rubyonrails.org/mailman/listinfo/rails
>> _______________________________________________
>> Rails mailing list
>> removed_email_address@domain.invalid
>> http://lists.rubyonrails.org/mailman/listinfo/rails
> _______________________________________________
> Rails mailing list
> removed_email_address@domain.invalid
> http://lists.rubyonrails.org/mailman/listinfo/rails

----
Bob H.                  -- 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/>
This topic is locked and can not be replied to.