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. <[email protected]>
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 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
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.
“Jean-François” == Jean-François [email protected] 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 D. <[email protected]>
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 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. - [email protected] - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant
http://trackmap.robotcoop.com
On 4/27/06, Calle D. [email protected] wrote:
starts working just fine.
You need @request.session[:user] = user, rather than simple
session[:user]
“Eric” == Eric H. [email protected] 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:
- 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. <[email protected]>
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 Apr 27, 2006, at 3:19 AM, Calle D. wrote:
“Eric” == Eric H. [email protected] 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. - [email protected] - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant
http://trackmap.robotcoop.com
On Apr 27, 2006, at 5:57 AM, Wilson B. wrote:
- 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. - [email protected] - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant
http://trackmap.robotcoop.com
You’d probably get more comments if you didn’t thread hijack.
b
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.
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,
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
[email protected]
http://lists.rubyonrails.org/mailman/listinfo/rails
Rails mailing list
[email protected]
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/
I see… I wasn’t aware that I was thread hijacking. I apologize.
-carl