Re: [Wtr-general] abnormal program termination error message while playing back a script
On 12/5/2006, vijay [EMAIL PROTECTED] wrote: Thanks Charley for your info. Now I have installed Ruby 1.82 (from the RubyForge site) after uninstalling Ruby 1.85. Thanks from me too. I'm now running Watir with Ruby 1.8.2 on XP Embedded, and showing how much slower this supposed thin client application is on slow hardware. :-) Who needs a load test tool when a single user already can't get good performance. -Danny ___ Wtr-general mailing list Wtr-general@rubyforge.org http://rubyforge.org/mailman/listinfo/wtr-general
Re: [Wtr-general] Set focus to original window
On 12/4/2006, Alan Jahns [EMAIL PROTECTED] wrote: Could it be that since after submitting the log in credentials the 2nd window closes and the first window takes a few secs to reload? Yes, I think that's probably the problem - your code has a race condition. There is a wait function that you normally don't have to call directly, because after an action that you'd want to wait for it to finish, Watir calls it for you. But in this case, since you have one window causing a change in another window, you'd have to take care of the synchronization yourself. Even if you wait until the page finished loading, there's still a race condition, because there's a chance (probably a small one) that you'd call wait before the first page even begins to reload, and the wait would return immediately because it's not loading anything yet. So in addition to the wait, I would recommend putting your You are signed in as test in a loop, so it tries several times over the course of several seconds before giving up. I'm not a seasoned Watir developer yet, but hopefully I've hit on the issue here. By the way, I don't think that focus is what you're looking for. Unlike many GUI test tools, in many cases IE doesn't actually need focus or to be in the foreground in order for Watir to work. I'd imagine that focus would be something you'd have to worry about if you use Watir's generic GUI automation, though. -Danny ___ Wtr-general mailing list Wtr-general@rubyforge.org http://rubyforge.org/mailman/listinfo/wtr-general
Re: [Wtr-general] Set focus to original window
On 12/4/2006, Alan Jahns [EMAIL PROTECTED] wrote: Well thanks a lot, you led me to the fix. It does seem to be a timing problem, I started googling to figure out how to do a loop as you suggested and while doing that found the sleep command, so I tried something like: ie2.button(:value, Sign In).click # take a nap to wait for first page to load sleep(25) I was hoping you wouldn't find that. :-) The hacker in me wants to point out that using sleeps to synchronize are both too slow and still don't technically remove the race condition. But the engineer in me says, hey, great, that will probably work in most or all of the cases you need it for, and the slower it is, the more likely it'll work. You pick which one you want to listen to. :-) Here's pseudocode for how I would approach it - ..child window initiates content change in parent window found = 0 for i in 1..10 ie.wait if desired content found in parent found = 1 break end end if found == 1 hurrah! -Danny ___ Wtr-general mailing list Wtr-general@rubyforge.org http://rubyforge.org/mailman/listinfo/wtr-general
Re: [Wtr-general] Checking whether images inside a table are enabled or disabled
On 12/4/2006, vijay [EMAIL PROTECTED] wrote: T...While entering into our application, all links, other than Instructions and Step 1. Details, should be disabled. ... I want to verify this with Watir. I am at a loss about how to do that. I would recommend looping through ie.links (or the appropriate frame) and making sure that nothing appears that's supposed to be disabled, by matching on the link text, e.g. match using /Step [2-6]/ etc. -Danny ___ Wtr-general mailing list Wtr-general@rubyforge.org http://rubyforge.org/mailman/listinfo/wtr-general
Re: [Wtr-general] how to tell when IE is *really* done
From: Bret Pettichord [EMAIL PROTECTED] I this that this patch might fix this problem: http://jira.openqa.org/browse/WTR-107 I believe that a correct wait procedure needs to check every frame. Thanks for the pointer. I've upgraded to 1.5.1.1127 to pick up this change. It doesn't quite fix the problem, though. The new wait code doesn't recursively descend into the frames - it only gets the direct children of the main page. The patch below makes it recursive, and gives me the correct behavior for my app. *** watir.rb.bakTue Nov 28 13:30:15 2006 --- watir.rbTue Nov 28 13:36:37 2006 *** *** 1676,1681 --- 1676,1700 # include Watir::Utils + def frame_wait(object, s) + if object.document.frames.length 0 + begin + 0.upto object.document.frames.length-1 do |i| + until object.document.frames[i.to_s].document.readyState == complete + sleep 0.2; s.spin + end + url = object.document.frames[i.to_s].document.url + @url_list url unless url_list.include?(url) + frame_wait(object.document.frames[i.to_s], s) + end + rescue WIN32OLERuntimeError + end + else + url = @ie.document.url + @url_list url unless @url_list.include?(url) + end + end + # Block execution until the page has loaded. def wait(no_sleep=false) @down_load_time = 0.0 *** *** 1709,1729 sleep 0.2; s.spin end ! if @ie.document.frames.length 0 ! begin ! 0.upto @ie.document.frames.length-1 do |i| ! until @ie.document.frames[i.to_s].document.readyState == complete ! sleep 0.2; s.spin ! end ! url = @ie.document.frames[i.to_s].document.url ! @url_list url unless url_list.include?(url) ! end ! rescue WIN32OLERuntimeError ! end ! else ! url = @ie.document.url ! @url_list url unless @url_list.include?(url) ! end @down_load_time = Time.now - start_load_time run_error_checks print \b if @enable_spinner --- 1728,1734 sleep 0.2; s.spin end ! frame_wait(ie, s) @down_load_time = Time.now - start_load_time run_error_checks print \b if @enable_spinner ___ Wtr-general mailing list Wtr-general@rubyforge.org http://rubyforge.org/mailman/listinfo/wtr-general
Re: [Wtr-general] [OT] Running scripts on machines without ruby
http://www.erikveen.dds.nl/rubyscript2exe/index.html I hear good things about it. I just tried it, and was impressed that it worked when I ran the executible on the same system where I built it. That's something that I haven't been able to get the open source Perl compiler to do. But when I copied it from an XP Pro SP2 box to an XP Embedded SP0 box, it ran for a few moments and then died with a segmentation fault. On repeated attempts, it died intermittently in two different places in watir.rb. I guess it's too much of a stretch to expect to run it on a different flavor of Windows. -Danny ___ Wtr-general mailing list Wtr-general@rubyforge.org http://rubyforge.org/mailman/listinfo/wtr-general
Re: [Wtr-general] [OT] Running scripts on machines without ruby
Okay, sorry, I jumped the gun on rubyscript2exe. I managed to get a full Ruby 1.8.5 install on my XP Embedded box, and I'm getting intermittent segmentation faults with that too. So rubyscript2exe is just faithfully producing the same bug that's in Ruby itself. Is anyone else using Ruby on Windows XP Embedded? I'm testing on a MaxTerm thin client. -Danny ___ Wtr-general mailing list Wtr-general@rubyforge.org http://rubyforge.org/mailman/listinfo/wtr-general
[Wtr-general] how to tell when IE is *really* done
I'm having trouble getting a script to tell me accurately when a page has finished rendering. I'm running Watir 1.4.1 with Ruby 1.8.5 on Windows XP Pro SP2. I'm clicking a link that opens a new browser window, then I attach to the window. The attach returns before the contents of the window are rendered. There is a lot of javascript processing going on to do the rendering - I'm guessing that IE is saying it's done when the code and data are all downloaded, even though Javascript is still executing. Adding extra calls to the wait method doesn't help - IE insists that it's no longer busy, according to ie.busy. The rendering can take 30 seconds or more. Can anyone suggest a way to determine when the page has been completely rendered? Or when Javascript code is not currently executing? The best idea I've had so far, which isn't a very good idea, is to use a heuristic to watch for some element of the page to appear in the document. In my case, this would require traversing a quagmire of nested frames to find the content. -Danny ___ Wtr-general mailing list Wtr-general@rubyforge.org http://rubyforge.org/mailman/listinfo/wtr-general
[Wtr-general] using Watir for single-user performance testing
I briefly mentioned how I've been using Watir in a blog post today - The Jury’s Still Out on OpenSTA (http://tejasconsulting.com/blog/?p=74). I'd be glad to elaborate on Watir's role in the toolchain, and discuss the necessity of using a browser-based test tool for single-user performance testing rather than a load test tool that does browser simulation. I'm testing a web application that uses Javascript heavily, so measuring the impact of the Javascript execution time is important. I was using Ruby and Squid to get low-level single-user inter-page timings, which a Perl script then used to edit the OpenSTA SCL code. Is anyone else using Watir for performance testing? -- Danny R. Faught Tejas Software Consulting http://tejasconsulting.com/ ___ Wtr-general mailing list Wtr-general@rubyforge.org http://rubyforge.org/mailman/listinfo/wtr-general
Re: [Wtr-general] Wtr-general Digest, Vol 33, Issue 7
My working hypothesis is that Danny's server only has Basic Auth in place for the first outer document presented to the user, while my server has Basic Auth in place for every document on the server. After exploring what's going on, I think this is likely true. I believe that the server is using basic authentication to validate the user and then set a session cookie. Once the cookie is set the basic authentication is no longer required. It's a strange app. So perhaps the authentication part of the goto method does not apply recursively to the elements on the page, which means it not very useful at all. One thing I started to pursue is to find an OLE interface to set the authentication internally as if the user had already entered it. I see that even when I tell IE to save the password, it still pops up the login dialog. So it's not good enough to get it to save the password in that way - IE needs to have the password set in its memory as if the user has entered it - as you suggested. Maybe doing the GUI automation isn't such a bad solution. But let's see if IE gives us this password setting mechanism before we give up. -Danny ___ Wtr-general mailing list Wtr-general@rubyforge.org http://rubyforge.org/mailman/listinfo/wtr-general
Re: [Wtr-general] simple solution for basic authentication
Maybe doing the GUI automation isn't such a bad solution. But let's see if IE gives us this password setting mechanism before we give up. How would we do this? I feel like i've already done this, but i'm not quite sure if you have something specific in mind. You mean GUI automation? I've seen discussions on this list about a couple of different tools for generic GUI automation, including AutoIT. I haven't explored them myself, though I've heard good things about AutoIT. I have looked at Samie and saw that it has some code that uses Perl's Win32::GuiTest library to deal with this dialog, though the code in Samie that calls it needs a lot more work in order to be productized. Given the conclusion about how IE's navigate method is flawed means that the authentication in Win32::IE::Mechanize is also broken for pages that contain elements that are protected by authentication. It looks like this authentication code was copied from LWP::UserAgent, which gives the user control over each individual element because it's not a browser-based library, and thus wouldn't necessily have the problem. It still might be interesting to prove that Win32::IE::Mechanize doesn't work on Chris' site. -Danny ___ Wtr-general mailing list Wtr-general@rubyforge.org http://rubyforge.org/mailman/listinfo/wtr-general
Re: [Wtr-general] simple solution for basic authentication
To productize it, I'd recommending adding a credentials method like Win32::IE::Mechanize uses. I don't understand the $realm argument in this API. Can you explain? Could we drop it? The realm is described here - http://httpd.apache.org/docs/1.3/howto/auth.html. It corresponds to the AuthName element of the .htaccess file, and the realm is shown in the login dialog in the browser (in IE 6, it's just above the User name field). I suppose the realm can be used to designate different login accounts for different areas of a web site. For a thorough implementation, Watir should track the realm like Win32::IE::Mechanize does, which only adds a small amount of complexity. Now that I think about it, I'm not sure how the browser knows whether each new URL request is within the same realm or not. However, since the realm matching seems to occur only on the client side, a quick and dirty implementation that ignores the realm (like my sample code does) would work for the most common cases where only one login is required for a site. -Danny ___ Wtr-general mailing list Wtr-general@rubyforge.org http://rubyforge.org/mailman/listinfo/wtr-general
Re: [Wtr-general] simple solution for basic authentication
I tried and failed, but I thought my problem was in the way IE handled the data. I'd love to be proven wrong: It works for me, hacking watir.rb with hardcoded credentials like so - def goto( url ) user = username pass = password auth = Authorization: Basic + Base64.encode64(user + : + pass) + \015\012 @ie.navigate(url, nil, nil, nil, auth) wait() sleep 0.2 return @down_load_time end I added a require 'base64' near the top. This is working for a site that's a huge mess of nested frames plus a swarm of small js, image, and css files, etc. I noticed that you hardcoded the base64 encoding of the credentials. Did you try to do it by doing the encoding on the fly? To productize it, I'd recommending adding a credentials method like Win32::IE::Mechanize uses. -Danny ___ Wtr-general mailing list Wtr-general@rubyforge.org http://rubyforge.org/mailman/listinfo/wtr-general
Re: [Wtr-general] RPC Server unavailable
w 1. Add time delays between the ie.close and ie.new or ie.start. This will give a chance for the ie.close to really close. 2. Don't close IE -- just reuse the existing client between tests. 3. Create an additional IE. As long as this lives, the IE server will continue to live and you can close and create IE windows without worry. I started getting the RPC server error in my script, when I changed it to close IE, clear the cache, and restart IE between iterations. The solution I'm trying, not quite on the list above, is this - # Close IE and make darn sure it's closed def closeIE(ie) while 1 begin ie.close rescue break end sleep 0.1 end end Seems to avoid the RPC error. I just bounce on ie.close until it throws an exception, before I try to open another IE window. ___ Wtr-general mailing list Wtr-general@rubyforge.org http://rubyforge.org/mailman/listinfo/wtr-general
[Wtr-general] simple solution for basic authentication
Howdy folks. I find myself on a project where I want to use a
browser-based test tool to record client-side performance metrics.
After playing with several such tools again, Watir again emerged as the
tool that I was first able to get a working script with.
But along the way, I noticed with some amazement that Perl's
Win32::IE::Mechanize module was able to handle the basic HTTP
authentication that gives so many people headaches with other tools. It
doesn't do it by automating the dialog asking for the login
information, but rather it prevents the dialog from appearing by
submitting the credentials right from the beginning. That means it
makes one fewer transaction with the web server (avoiding the first
request that gets a 401 response), but perhaps I can live with that.
Has anyone else tried to implement this with Watir? If not I may try it
myself. Here's the core of it in IE::Mechanize where it formulates the
Authorization header, really simple stuff:
sub __authorization_basic {
my( $user, $pass ) = @_;
defined $user defined $pass or return;
require MIME::Base64;
return Authorization: Basic .
MIME::Base64::encode_base64( $user:$pass ) .
\015\012;
}
___
Wtr-general mailing list
Wtr-general@rubyforge.org
http://rubyforge.org/mailman/listinfo/wtr-general
