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.
9d7d8ef2179661d6b30e180fa588cd45?d=identicon&s=25 Calle Dybedahl (Guest)
on 2006-04-23 19: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 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
6805b35d0a8ea3ede0a7da2d4cf5ae77?d=identicon&s=25 Jonathan Weiss (Guest)
on 2006-04-23 20:25
(Received via mailing list)
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
13ea48f056b19349027d2f4a6921a46a?d=identicon&s=25 Jean-François (Guest)
on 2006-04-23 20: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.
9d7d8ef2179661d6b30e180fa588cd45?d=identicon&s=25 Calle Dybedahl (Guest)
on 2006-04-25 09:08
(Received via mailing list)
>>>>> "Jean-François" == Jean-François  <jf.web3@gmail.com> 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 Dybedahl <calle@cyberpomo.com>
		 http://www.livejournal.com/users/cdybedahl/
		"Let me answer that question with a headbutt."
		      -- Buffy, Buffy the Vampire Slayer
58479f76374a3ba3c69b9804163f39f4?d=identicon&s=25 Eric Hodel (Guest)
on 2006-04-26 20:36
(Received via mailing list)
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
9d7d8ef2179661d6b30e180fa588cd45?d=identicon&s=25 Calle Dybedahl (Guest)
on 2006-04-27 12:20
(Received via mailing list)
>>>>> "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
25e11a00a89683f7e01e425a1a6e305c?d=identicon&s=25 Wilson Bilkovich (Guest)
on 2006-04-27 14:57
(Received via mailing list)
On 4/27/06, Calle Dybedahl <rails@cyberpomo.com> wrote:
>
>
>
> starts working just fine.
> --

You need @request.session[:user] = user, rather than simple
session[:user]
58479f76374a3ba3c69b9804163f39f4?d=identicon&s=25 Eric Hodel (Guest)
on 2006-05-03 19:09
(Received via mailing list)
On Apr 27, 2006, at 5:57 AM, Wilson Bilkovich 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 Hodel - drbrain@segment7.net - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant

http://trackmap.robotcoop.com
58479f76374a3ba3c69b9804163f39f4?d=identicon&s=25 Eric Hodel (Guest)
on 2006-05-03 19:09
(Received via mailing list)
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.

>>      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 Hodel - drbrain@segment7.net - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant

http://trackmap.robotcoop.com
D566a291d8ee7c013649e47b3769d981?d=identicon&s=25 Carl Lerche (Guest)
on 2006-05-03 19: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.
4005a47a8f2ceee49670b920593c1d52?d=identicon&s=25 Ben Munat (Guest)
on 2006-08-03 13:33
(Received via mailing list)
You'd probably get more comments if you didn't thread hijack.

b
D566a291d8ee7c013649e47b3769d981?d=identicon&s=25 Carl Lerche (Guest)
on 2006-08-03 14:22
(Received via mailing list)
I see... I wasn't aware that I was thread hijacking. I apologize.

-carl
4005a47a8f2ceee49670b920593c1d52?d=identicon&s=25 Ben Munat (Guest)
on 2006-08-03 14: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
E3c79c779c0b390049289cdfe7cb9705?d=identicon&s=25 Bob Hutchison (Guest)
on 2006-08-03 14: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 Munat 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
>> 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/>
This topic is locked and can not be replied to.