Re: [Selenium-users] HOW TO: Testing remote sites with Selenium andInternet Explorer
Nate Kirby wrote on 10/21/2005 02:55:45 PM: I also could not get these directions to work at all in Firefox. I thought selenium was browser agnostic. Regarding Firefox, let me make a quick note: I don't think anyone else has noticed this or mentioned this... But the Firefox-only Selenium Recorder lets you test foreign sites (like Google) with ease... Since it is a chrome application... It is not subject to the same security policies that plain old Selenium is subject to... If you want to use Firefox to test Google using the HTML table style of selenium, I would investigate the Selenium Recorder further... Okay, for a longer answer Selenium is browser agnostic... at its core it's just HTML and JavaScript and a few stylesheets. However, hacking around security protections to test a remote site is mostly not browser agnostic... Not too many apps try to do what Selenium is trying to do... In fact, Selenium is trying to do what most security experts would consider a security bug Selenium is *merely* JavaScript. It is JavaScript running in one frame, that drives a website in a child iframe. All is fine if Selenium is installed on the same site and server as the one you are testing... But if you try to test some foreign site, like Google... this is called cross site scripting... and has been locked down and labeled a security hole by everyone in the universe. Unfortunately, turning off this security for the benevolent purposes of testing with Selenium is not easy or as straight forward as you'd hope. However, one of the easiest ways to get around the security sandbox that Selenium sits in, and to thus be able to test foreign sites, is use an HTA application. By definition... this is Windows/Internet Explorer only. Microsoft turns off lots of JavaScript security protections that you'd normally see in a web page if you merely rename your .html to .hta So it's a trade-off... Sadly, Microsoft has mostly disowned its HTA work... Perhaps, HTML+JavaScript+No Security as a replacement for writing desktop apps was hurting sales of Visual Studio. ;-) There are a few other alternatives, though...if you want to test foreign sites in a truly browser agnostic way with Selenium... you could install the Selenium Standalone Server on your computer... The Standalone Server does its security workaround magic by using James Marshall's excellent reverse proxy script to make local selenium and the foreign site all look like they're coming from localhost... thus getting around JavaScript security. A hack, yes... and it works in most cases, but it is dark magic in how it works The standalone server also throws in a few extra goodies in allowing you to write your test scripts in any language you prefer via a built-in XML-RPC gateway. The down side to using the Standalone Server is that I haven't had/made the time to keep it up-to-date lately. Though I hope that changes in the near future. I think there are three futures for Selenium. (2 of which can be used for testing remote sites)... 1) Plain old Selenium --- you embed it in your site with all your other html and JavaScript files... Tests are written as HTML tables (or maybe straight JavaScript in the future)... However, you can't test a remote site in this configuration because of security restraints enforced by all browsers. 2) Standalone Server Selenium -- uses some reverse proxy trickery to work around cross site scripting security... It works for testing a remote site, but uses dark, magic. And magic is bad. 3) Expand the use of browser plug-ins like Selenium Recorder... Plug-ins are probably the least hacky.and magical.. since the browser implicitly trusts a plug-in and allows it do anything... However, this is *more work*... We would need to write a browser plug-in for each major browser and keep them up-to-date with each new browser release. Google's Toolbar, the GreaseMonkey plug-in would be used as inspiration. Actually, I imagine some kind of mash-up of Greasemonkey and Selenium Recorder would be the result. By the way, Selenium Recorder rocks and I'd like to see its development continue. I'll leave the HTA Selenium thing out of the future since its not cross browser and not cross platform and there are no guarantees from Microsoft that they'll keep supporting it. - Jason ___ Selenium-users mailing list Selenium-users@lists.public.thoughtworks.org http://lists.public.thoughtworks.org/mailman/listinfo/selenium-users
Re: [Selenium-users] HOW TO: Testing remote sites with Selenium andInternet Explorer
Nate Kirby wrote on 10/21/2005 02:55:45 PM: I also could not get these directions to work at all in Firefox. I thought selenium was browser agnostic. Regarding Firefox, let me make a quick note: I don't think anyone else has noticed this or mentioned this... But the Firefox-only Selenium Recorder lets you test foreign sites (like Google) with ease... Since it is a chrome application... It is not subject to the same security policies that plain old Selenium is subject to... If you want to use Firefox to test Google using the HTML table style of selenium, I would investigate the Selenium Recorder further... Okay, for a longer answer Selenium is browser agnostic... at its core it's just HTML and JavaScript and a few stylesheets. However, hacking around security protections to test a remote site is mostly not browser agnostic... Not too many apps try to do what Selenium is trying to do... In fact, Selenium is trying to do what most security experts would consider a security bug Selenium is *merely* JavaScript. It is JavaScript running in one frame, that drives a website in a child iframe. All is fine if Selenium is installed on the same site and server as the one you are testing... But if you try to test some foreign site, like Google... this is called cross site scripting... and has been locked down and labeled a security hole by everyone in the universe. Unfortunately, turning off this security for the benevolent purposes of testing with Selenium is not easy or as straight forward as you'd hope. However, one of the easiest ways to get around the security sandbox that Selenium sits in, and to thus be able to test foreign sites, is use an HTA application. By definition... this is Windows/Internet Explorer only. Microsoft turns off lots of JavaScript security protections that you'd normally see in a web page if you merely rename your .html to .hta So it's a trade-off... Sadly, Microsoft has mostly disowned its HTA work... Perhaps, HTML+JavaScript+No Security as a replacement for writing desktop apps was hurting sales of Visual Studio. ;-) There are a few other alternatives, though...if you want to test foreign sites in a truly browser agnostic way with Selenium... you could install the Selenium Standalone Server on your computer... The Standalone Server does its security workaround magic by using James Marshall's excellent reverse proxy script to make local selenium and the foreign site all look like they're coming from localhost... thus getting around JavaScript security. A hack, yes... and it works in most cases, but it is dark magic in how it works The standalone server also throws in a few extra goodies in allowing you to write your test scripts in any language you prefer via a built-in XML-RPC gateway. The down side to using the Standalone Server is that I haven't had/made the time to keep it up-to-date lately. Though I hope that changes in the near future. I think there are three futures for Selenium. (2 of which can be used for testing remote sites)... 1) Plain old Selenium --- you embed it in your site with all your other html and JavaScript files... Tests are written as HTML tables (or maybe straight JavaScript in the future)... However, you can't test a remote site in this configuration because of security restraints enforced by all browsers. 2) Standalone Server Selenium -- uses some reverse proxy trickery to work around cross site scripting security... It works for testing a remote site, but uses dark, magic. And magic is bad. 3) Expand the use of browser plug-ins like Selenium Recorder... Plug-ins are probably the least hacky.and magical.. since the browser implicitly trusts a plug-in and allows it do anything... However, this is *more work*... We would need to write a browser plug-in for each major browser and keep them up-to-date with each new browser release. Google's Toolbar, the GreaseMonkey plug-in would be used as inspiration. Actually, I imagine some kind of mash-up of Greasemonkey and Selenium Recorder would be the result. By the way, Selenium Recorder rocks and I'd like to see its development continue. I'll leave the HTA Selenium thing out of the future since its not cross browser and not cross platform and there are no guarantees from Microsoft that they'll keep supporting it. - Jason ___ Selenium-users mailing list Selenium-users@lists.public.thoughtworks.org http://lists.public.thoughtworks.org/mailman/listinfo/selenium-users
Re: [Selenium-users] HOW TO: Testing remote sites with Selenium and Internet Explorer
Vernon Viles wrote on 10/21/2005 01:22:38 PM: Here is a how to for people that are just starting with selenium and want to get up and running quickly with Internet Explorer. Vernon, thank you for (re)compiling this information. Like I said, in my other reply to Nate, though... Selenium's true goal is to be a cross-browser and cross-platform testing tool that lets you test web apps *as they are* using a real browser to test all the crazy DHTML and AJAX that you can throw at it. The HTA solution was a quick pragmatic hack if you're more interested in testing a remote site, and less concerned that it's Windows/IE only. -Jason ___ Selenium-users mailing list Selenium-users@lists.public.thoughtworks.org http://lists.public.thoughtworks.org/mailman/listinfo/selenium-users
Re: [Selenium-users] Using selenium for Frames based website
This started on the user's list, but I'm cc'ing this to the developer's list... If folks want to talk about user workarounds for supporting frames in Selenium... replies should go to Users' list. If folks want to talk about developer implementation of supporting frames in Selenium... replies should go to Dev list. Ajit Zadgaonkar wrote on 10/25/2005 02:25:51 PM: Is anyone aware of any work arounds, private fixes that would let selenium work for webpages having frames / Iframes ? There were some experimental patches submitted to the developer mailing list many months ago... Other than that... sorry, you'll have to hack the source. Believe me, this is the #1 missing feature in Selenium... If someone can give us a high quality patch, we'll accept it and crank out a new release. (Which reminds me, if someone can dig up those experimental patches on the mailing list, confirm they work with a recent version of Selenium, and submit several some Selenium tests cases showing that it works in lots of different scenarios, I'd be very happy. Or at least, let us know what the remaining issues are with those patches.) The sticky point with frames is how Selenium deals with pageLoad events... When you click on a button Selenium listens for a pageLoad event to fire before continuing on with the rest of the script. Selenium adds that listener as needed dynamically With frames, Selenium would need to add that listener on all sub frames... Perhaps we could punt on the pageLoad issue if you just added a wait command after triggering any action that would cause a page load event. In that case, you just hope the new page is ready for new commands before the wait time period expires. This is how version 0 of Selenium worked back in the day. Other issues... Selenium itself uses frames (iframes, technically) to work its magic... The main Selenium code runs in the main window and controls the application under test in an iframe... Some sites do not like being wrapped in that iframe and expect to be the main frame... There is code in Selenium's codebase that lets you run your AUT in a separate window (not in an iframe), but I'm not sure how often if its used, or what issue there are with it.) Another issue... all the element locator commands like type and click use a search function to find an element on the page. Selenium currently expects to search one child iframe. These commands might need to be hacked to dynamically search all child window elements, whether they exist in frames or iframes (or frames within frames within frames, etc.) You might be able to skirt around this issue if you give a very precise DOM element locator expression that can find the element starting at the root element. For example: | click | document.frames[0].document.form[0].user_name_field || Good Luck and Patches Welcome! - Jason ___ Selenium-users mailing list Selenium-users@lists.public.thoughtworks.org http://lists.public.thoughtworks.org/mailman/listinfo/selenium-users
Re: [Selenium-users] Mouse Events...
Nate Kirby wrote on 11/02/2005 05:23:05 PM: Anyone out there got any experience using selenium to drive mouse events that are more complex than clicking like dragging. I personally don't have that experience, but I'm very eager to see if Selenium could do such a thing. Specifically, I'd like to see Selenium be able to test new Web 2.0 tricks like: * dragable lists in script.aculo.us (http://wiki.script.aculo.us/scriptaculous/show/SortableListsDemo) * drawing in the new canvas tag in Firefox 1.5 (Link only works in Firefox 1.5 and Safari -- http://ponderer.org/download/canvas_demo/) The key thing to know is that Selenium at its core is just HTML and JavaScript... so if JavaScript can do it, Selenium can do it. Once you figure out how to script the dragging of elements in JavaScript, you can edit Selenium's user-extensions.js file to add a new drag command to add to your HTML table tests. Also, I know for sure you can trigger most any event in JavaScript, even mouse events... However, if you use JavaScript to simulate dragging, your visible mouse cursor stays under your control (unless you simulate that with an animated cursor.gif element). - Jason ___ Selenium-users mailing list Selenium-users@lists.public.thoughtworks.org http://lists.public.thoughtworks.org/mailman/listinfo/selenium-users
[Selenium-users] User poll -- which Selenium test case syntax would you prefer?
I'd like to get opinions on preferred test syntax from Selenium users... (I'm cc'ing the dev list on this 'cause this it does have an effect on development, but let's keep the thread on the user's list for the time being.) Which syntax would you prefer as the source syntax of your test scripts: Option 1 trtdtype/tdtduser_name/tdtdjason/td/tr Option 2 type user_name jason Option 3 type jason into field named user_name Option 4 field(name=user_name).type(jason) As a programmer, which would you prefer and why? Which option do you think your end users would prefer and why? Thanks! -Jason ___ Selenium-users mailing list Selenium-users@lists.public.thoughtworks.org http://lists.public.thoughtworks.org/mailman/listinfo/selenium-users
Re: [Selenium-users] Conditional checks
Rahul Chaturvedi wrote on 11/14/2005 03:17:16 AM: Problem: depending upon some condition I need to verify some text or click some link.(viz: If some element/text is present then only do something otherwise do something else) following is the rough flow chart kind of thing just to make it more clear: (in my test case I want a feature like this)- if (some condition ) then command|target|value else command|target|value This condition is picked up from the page its showing. How can this be done ? Your urgency in replying will be highly appreciated. I think we should add this kind of syntax to tables-mode Selenium tests. I don't think it's even hard to do. The problem is that each new syntax or command we add is organic and evolutionary. When you develop a language that way (without design) you get Perl and PHP. Yuck. So my hesitation in adding new syntax is to make sure it fits into a larger vision of the future of the syntax. If I can satisfy that fear, then I'd say let's do it. Regardless, Selenium could use some kind of Master Plan. Of course, in developing that plan, we'll need to be careful to avoid the You Ain't Going To Need It aspects of Big Design Up Front :-) At the moment, Selenium table tests work great when you *don't* need conditionals or looping. The classic case for table-style Selenium is click this, do that, verify this, done. If you need programming logic like conditionals and looping, the commonly used technique is to use one of the language specific drivers (Perl, Python, Ruby, Java, etc.) and use all the tools available to you in those real languages. The problem with those drivers is that they are more complex to instrument correctly, and they require a driving process (on the client or server) to send commands to the browser. With those drivers, you get all the advantages of a real language, but you lose the simplicity of just going to the TestRunner.html page and clicking run. The middle of the road option is doing all the complex stuff in a Selenium users command written in JavaScript and call it from your Selenium test. Hope this helps! -Jason Huggins ___ Selenium-users mailing list Selenium-users@lists.public.thoughtworks.org http://lists.public.thoughtworks.org/mailman/listinfo/selenium-users
Re: Re: [Selenium-users] Automated log in?
David Niergarth wrote on 11/22/2005 03:28:23 PM: Thanks. I had tried this -- turned out it wasn't working due to a ';' in the password, which is apparently not URL-friendly. I'm able to do this now using driven Selenium. :) Here's to questions that I know how to answer. :-) -Jason ___ Selenium-users mailing list Selenium-users@lists.public.thoughtworks.org http://lists.public.thoughtworks.org/mailman/listinfo/selenium-users
