This is a work in progress. Please feel free to ask questions and/or +provide answers; send email to the Selenium users email address at selenium-users@lists.public.thoughtworks.org.
+It is used for functional or system testing web applications. These tests +are also sometimes called acceptance, customer, or integration tests. Selenium is not meant for unit testing.
+Question: +I was trying to write a simple script that does a google search. +I have been running into all sorts of problems. Does this work for you? +Here is my test:
| Test Type + |
+ ||
| open | +http://www.google.com/ | ++ |
| type | +q | +testing tools | +
| click | +submitButton | ++ |
Answer: +The quick answer is that because of cross-site scripting security built into +JavaScript engines in all browsers, you can't edit the content of a web page +from another domain. The foreign page will probably load correctly and be visible +in the test runner window, but Selenium won't be able to query or edit its contents. +In other words, you can't run selenium on "foo.com" and +run a test that edits values and clicks buttons against "bar.com". So, in +its current form, you can't "script" google.com because your script isn't +currently hosted on google.com. When Selenium and the application you are +testing is hosted on the same domain, however, you do not run into the +cross-site scripting security feature/limitation.
+You read more about cross-site scripting here: http://www.devarticles.com/c/a/JavaScript/JavaScript-Security/
+Also, if cross-site scripting security didn't exist, be careful about your +field and button references in your tests. The current version +of Selenium uses the "id" attribute of the object you are referring to in your +test. The search field and submit button at google.com have "name" attributes, +but not not "id" attributes. Therefore, Selenium wouldn't be able to find the objects. +Future versions of Selenium will be able to search for objects by more than +just the id attribute, though.
+There are a few ways around cross-site scripting to access a remote server. +You could use a combination of proxying and URL rewriting in Apache to +trick the browser into the thinking the application and the testing tool +are coming from the same domain.
+Another option is to run Selenium as an "HTA" application, or "HTML +Application" in Internet Explorer. HTA applications run in the security +context of any trusted application on the client, so there is no cross-site +scripting limitation. (You can find out more here: +http://msdn.microsoft.com/workshop/author/hta/overview/htaoverview.asp) The +equivalent to this "security-free" client on the Mozilla side of the fence +would be to write a XUL wrapper/extension.
+Also, please see the answer to the related question: "Why can't I script google.com".
+The developers on the Selenium project use Mozilla Composer to +create plain HTML text files for their tests. +By default, Mozilla Composer writes very clean HTML without any extra, unnecessary markup.
+Future versions of Selenium may support RST (ReStructred Text), or wiki-table +syntax, natively. However, you are free to use another format now, +as long as you remember to generate the HTML files from your source files, +either during your build process or dynamically at run-time.
+| Author: | Jason Huggins | +
|---|---|
| Created Date: | 11/05/2004 | +
| Modified Date: | 11/05/2004 | +
| Created With: | reStructuredText: http://docutils.sourceforge.net/rst.html | +