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.
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.
-
-
diff --git a/tests/FunctionalTests/selenium/doc/FAQ.txt b/tests/FunctionalTests/selenium/doc/FAQ.txt
deleted file mode 100644
index ad9894ee..00000000
--- a/tests/FunctionalTests/selenium/doc/FAQ.txt
+++ /dev/null
@@ -1,127 +0,0 @@
-===========================================
- Selenium Frequently Asked Questions
-===========================================
-
-.. Please note that until there's a Q&A-specific construct available,
- this FAQ will use section titles for questions. Therefore
- questions must fit on one line. The title may be a summary of the
- question, with the full question in the section body.
-
-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`__.
-
-.. _let us know:
-__ mailto:selenium-users@lists.public.thoughtworks.org
-
-
-.. contents::
-.. sectnum::
-
-
-
-
-Selenium
-========
-
-What is Selenium used for?
---------------------------
-
-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.
-
-
-
-Why can't I script google.com?
-------------------------------
-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|.
-
-.. |test| raw:: html
-
-
-
-
-
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.
-
-
-How can I run my test against a foreign or remote server and get around cross-site scripting security?
-------------------------------------------------------------------------------------------------------
-
-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".
-
-
-How do you create test tables?
-------------------------------
-
-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
\ No newline at end of file
diff --git a/tests/FunctionalTests/selenium/doc/contact.html b/tests/FunctionalTests/selenium/doc/contact.html
deleted file mode 100644
index b109444d..00000000
--- a/tests/FunctionalTests/selenium/doc/contact.html
+++ /dev/null
@@ -1,23 +0,0 @@
-
-
-
-
- Selenium Contact
-
-
-
-For more information about Selenium, please use Confluence and the standard mailing lists below.
-
-This page details important information for people developing drivers
-for Selenium.
-
Same Origin Policy
-This is a security issue that affects all modern browsers. It is well
-described here,
-but for our purposes, it constrains the way that a
-JavaScript in a browser may interoperate with other open frames and
-windows. In short, the Selenium JavaScript app must come from (or
-appear to) the same origin as the AUT.
-
The Driver
-The driver has a number of duties. These are typically..
-
-
Instantiating the web server with a dynamic app (servlets for
-Java)
-
Launching a browser with a with a URL that makes sense for
-connecting to that server
-
providing an API to such that commands can be routed though the
-dynamic app to the browser
-
-
Local, Remote and URLs
-
-An application may be testable in a remote location by humans, but for
-scripted testing and the need for the driver to dynamically drive the
-browser, it is optimal for the driver to be on the same machine as that
-serving the AUT and the browser testing it.
-
-Thus, an application as deployed ...
-
-
-
-... would appear like so for the purposes of testing ...
-
-
-
-As with the standalone version of Selenium, there are a number of files
-(HTML and JavaScript) that comprise the bulk of the testing framework
-and sit in the browser as testing occurs. It makes most sense to put
-these in a virtual directory on the same server ...
-
-
-
-The dynamic webapp needs to be similarly mounted ...
-
-
-
-As the dynamic is the link between what is happening in the browser and
-the driving process, it we need to somehow have an instance reference
-to it. This is easier in some languages and web servers than
-others. Also full programatic start/stop control over the web
-server is not always possible for some larger web servers
-implementations.
-
Reply/Request Architecture
-Because a browser cannot open a socket and listen on it, we must
-effectively initiate communication thru the driver on the browser side.
-Ignoring the possibilities granted by keep-alive, we simply poll from
-the browser to the server and pick up commands to process inside the
-browser. Results of commands are also passed back to the dynamic
-hander over the same mechanism. These are in fact done in the same HTTP
-request. The results from the previous
-command go back as query string parameters, and the next command is communicated in a
-text/plain document
-
-The previous/next business introduces some complexity on the driver
-side of the design. Namely hidden behind the API, the driver must
-manage queues for the outgoing commands and the (some time later)
-incoming responses. Java, until 1.5, did not have a blocking
-queue to make this easy. Most other languages did.
-
Selenese
-
-
-
-
Selenese is the contrived (and mostly hidden) wire language
-that the
-driver uses to speak to the browser-bot through the dynamic
-handler. It uses HTTP for its transport, and is quite
-simple.
-
-Responses come from the browser to the driver in a query
-string like
-
- commandResult=OK,
-
-Commands go from the driver to the
-browser-bot in a text/plain document:
-
- | open | /foo/bar.html | |
-
-This two way communication is of course invisible to the observer.
-
The
-BrowserBot, by understanding Selenese, allows a process other than the
-browser itsself to direct events on the Application Under Test.
-
-The Selenese language is simple enough to be commandable by any
-language that has an API that can handle HTTP requests.
-
-Thus, Selenese allows many different open, free or closed license
-drivers to interoperate with the BrowserBot.
-
-
-
-
Choregraphy
-The driver cleary has some fairly heavy things to do. It is
-important for some robustness to be built into the design. For example
-it may take a long time for the browser to be instantiated on a
-particular platform. It is appropriate for wait timeouts to be
-generous here. Similarly whilst issuing individual commands it is
-important for the driver to wait a sufficient amount of time for a
-command to execute (and its result to come back). For the most
-part on a localhost setup, it will be because the AUT is slow, but it
-could be because some break in the app means that there will be no
-subsequent response. Some timeout regime should be able to
-recover from, mark a test as failed (for reasons of timeout), and start
-again with the next test.
-
-
-
-
diff --git a/tests/FunctionalTests/selenium/doc/driven.html b/tests/FunctionalTests/selenium/doc/driven.html
deleted file mode 100644
index a5f33dff..00000000
--- a/tests/FunctionalTests/selenium/doc/driven.html
+++ /dev/null
@@ -1,206 +0,0 @@
-
-
-
-
-
- Driven Selenium Reference
-
-
-
-
-
-
Overview
-Driven Selenium is where the browser is under the the control of an
-adjacent process. That process is either a Java, .Net, Ruby or Python
-application and it is typically run in conjunction with a unit testing
-framework like JUnit or NUnit. Also possible, is a console application
-driving a browser interactively.
-
Selenium & Selenese
-The key to this mode of operation is manner in which the browset-bot
-takes instruction from the driver. If it were possible, the
-browser-bot's javascript would open a server socket and await requests
-from the driver. It is against the rules for browser embedded
-javascript, to open ports for incoking requests as it would be a
-general breach of security for the client-OS that the browser is
-running on. What a browser can do is open addition requests to
-the same server that its source came from. See http://www.mozilla.org/projects/security/components/same-origin.html
-for more info.
-
-To overcome the limitations of Javascript in a browser page is the page
-continuously requests pages from the driver (which has conveniently
-opened a web server). The pages which are retrieved from the server are
-in fact plain text and each is an individual instruction from the
-driver for what the browser-bot is to do next. E.g. -
-
- | open | /foo/bar.html | |
-
-We refer to this architecture are reply/request rather than the more
-ususal request/reply.
-
-The test script is one that would be recognisable to people adept with
-unit test frameworks :
-
-For Java -
-
- public void testOKClick() {
- selenium.verifyTitle("First Page");
- selenium.open("/TestPage.html");
- selenium.click("OKButton");
- selenium.verifyTitle("Another Page");
- }
-
-The difference from normal unit testing is that as part of the startup,
-three major things have to happen:
-
-
The test framework needs to publish a fresh copy of the
-Application Under Test (AUT).
-Selenium prefers to mount its own web server temporarily for the
-purposes of testing.
-
The test framework needs to publish the static Selenium pages
-(refer selenium dir in TestRunner mode above) in an apparent directory
-on the same web server as (1).
-
The test framework needs to open a browser instance and point it
-to Selenium.html served in (2) above.
-
-As each of these isa fairly time consuming operation, it is best that
-all three of those happen in a one time setup mode. As such, and
-even though these leverage a unit testing framework, this is definately
-for acceptance or functional testing.
-
Example Setup
-
-
-
For Java -
-
- selenium = new DefaultSelenium("c:\foo\bar-web-app\");
-
-The above will instantiate a web server using Jetty, and
-publish it at http://localhost:8080. The Selenium pages will appear to
-be run from http://localhost:8080/selenium-driver. The default browser
-for Windows, Linux or Mac will be instantiated and directed to accept
-test instructions from the driver.
-
-The above would ususally be done in a setup method if under unit test
-control. See http://junit.sourceforge.net/doc/faq/faq.htm#organize_3
-for advice on one time setup for Java.
-
-A more complex case could be -
-
- selenium = new DefaultSelenium(new
-TomcatCommandProcessor("c:\foo\bar-web-app"), new
-MyOperaBrowserLauncher()),
-
-
-The best way to deply the driven form of Selenium is where an embedded
-web server is used. With the Java version, this could be Jetty or Tomcat.
-
-In advance of a series of selenese instructions being issued to the
-browser, a web server containing the AUT and some static pages for
-Selenium itself will be programmatically started and used to
-communicate selenese instructions to the browser. When the driver
-process is complete the web server will be programmatically stopped.
-
-
[ For release 0.2 - this is the only
-mode that really works. Those below will be fine for 0.3 and above ]
-
-
Adjacent Web Server
-
-By adjacent we mean a process on the same machine as the driver. As
-such it would appear as localhost to browsers.
-
-For the .Net driver embedded is very unlikely as Internet Information
-Server is running in its own process. For the Java driver, this could
-simple be a necessary choice - i.e. the deployment target is WebLogic
-or
-WebSphere which are not too embeddable.
-
-In this scenario we suggest you deploy a small web-app alongside the
-AUT that will liase between the driver process and the browser. Of
-course, there is less fine grained control over the starting and
-stopping of the server and indeed the version of the AUT. If the web
-server supports it, it is best to copy a fresh version of the AUT to
-the underlying directory that the web-app is mapped to. We call the
-small web-app the selenese proxy. It does of course slow things down a
-fraction.
-
-Selenese-proxy
-
-If you can deploy a copy of the selenese proxy to remote web server,
-and configure it to forward requests to your machine, then you can
-essentially script that remote web app. The downside of this is that
-that remote machine can essentially only be driven from the machine
-that is configured to drive it. i.e. it would need to be reconfigured
-to be driven from elsewhere. The upside is that you can to a great
-extent mix and match your technologies to achieve this proxying (a Java
-driver could use a Python selenese-proxy script a web-app).
-
Nearby Web Server
-
-This is where the AUT is running on a nearby testing stack or dedicated
-development box (not the developer's own workstation).
-
-To achieve this the selenese proxy needs to be deployed again, this
-time to that nearby machine. It will need to be reconfigured to
-indicate that selenese traffic is either forwarded to a particular
-machine.
-
-
Remote Web Server
-
-This is where the AUT is running on a remote machine, which you have no
-control over. A good example would be www.google.com. It is
-worth pointing out that this is of more interest to hackers or data
-harvesters than testing professionals, as what self respecting
-development group would prevent you from deploying at least the
-Selenese Proxy webapp to a testing stack.
-
-Funnel
-
-We are writing an application called the funnel that can help us
-overcome the same
-origin issue that is key to Selenium. It essentially makes a
-selenium-driver/ directory appear on a remote web site for the purposes
-of the browser.
-
-
-
-Selenium is a test tool for web applications. Selenium tests run
-directly in a browsers, just as real users do. And they run in
-Internet Explorer, Mozilla and Firefox on Windows, Linux and Macintosh. No
-other test tool covers such a wide array of platforms.
-
-
-
-
Browser compatability testing.
-Test your application to see if it works correctly on different
-browsers and operating systems. The same script can run on any Selenium
-platform.
-
-
System functional testing.
-Create regression tests to verify application functionality and user
-acceptance.
-
-
-Selenium
-uses a unique mechanism which allows it to run on so multiple
-platforms. Installed with your application webserver, Selenium
-automatically deploys it's JavaScript automation engine -- the Browser
-Bot -- to your browser when you point it at the Selenium install point
-on your webserver. Thus, you must have write access to the machine your
-web application server is running on to install Selenium.
-
-
"Considering the simplicity of it, it is
-almost surprising that no one has thought of doing this previously. The
-framework is simple and the code is neat and very maintainable.
-Sometimes it takes a work of genius to find the uncomplicated solution
-to a potentially complicated problem." - Antony Marcano
-
-
-
-
Selenium was
-developed by team
-of programmers and testers at
-ThoughtWorks. It is
-open-source software and can
-be downloaded and used without charge. It is currently under active
-development by our team. Stay tuned for updates and further
-announcements.
-
-
-ThoughtWorks is a leader in Agile development methods for enterprise
-software development. Selenium is designed specifically for the
-acceptance testing requirements of Agile teams. However, teams
-using more traditional development will also find it useful.
-
Supported Browsers and Platforms
-
-
-
-
-
-
-
Internet
-Explorer
-
-
Mozilla
-
-
Firefox
-
-
Safari
-
-
-
-
Windows XP
-
-
6.0
-
-
1.6+, 1.7+
-
-
0.8+, 0.9+, 1.0
-
-
-
-
-
-
Red Hat Linux
-
-
-
-
1.6+, 1.7+
-
-
0.8+, 0.9+, 1.0+
-
-
-
-
-
-
Mac OS X 10.3
-
-
not supported
-
-
1.6+, 1.7+
-
-
0.8+, 0.9+, 1.0+
-
-
1.3+
-
-
-
-
-
-
-
-
How does Selenium Work?
-
-Selenium uses JavaScript and Iframes to embed a test automation
-engine in your browser. This technique should work with any
-JavaScript-enabled browser. Because different browsers handle
-JavaScript somewhat differently, we usually have to tweak the engine to
-support new browsers.
-
Where did Selenium Come From?
-Selenium grew out of a testing framework that was
-developed to acceptance-test the functionality of ThoughtWorks' new
-web-based time & expense reporting application. It was written by
-Jason Huggins, Paul Gross and Jie Tina Wang.
-
Jason
-started demoing the test framework for various colleagues. Many were
-excited about its immediate and intuitive visual feedback, as well as
-its potential to grow as a reusable testing framework for other web
-applications.
-And Selenium was born.
-
-
Having Trouble?
-Check out our Frequently
-Asked Questions page
-for more information.
-
-
diff --git a/tests/FunctionalTests/selenium/doc/images/Adjacent.png b/tests/FunctionalTests/selenium/doc/images/Adjacent.png
deleted file mode 100644
index 6da4ad66..00000000
Binary files a/tests/FunctionalTests/selenium/doc/images/Adjacent.png and /dev/null differ
diff --git a/tests/FunctionalTests/selenium/doc/images/Embedded.png b/tests/FunctionalTests/selenium/doc/images/Embedded.png
deleted file mode 100644
index 8e5967d7..00000000
Binary files a/tests/FunctionalTests/selenium/doc/images/Embedded.png and /dev/null differ
diff --git a/tests/FunctionalTests/selenium/doc/images/SmallAdjacent.png b/tests/FunctionalTests/selenium/doc/images/SmallAdjacent.png
deleted file mode 100644
index 3cf28aec..00000000
Binary files a/tests/FunctionalTests/selenium/doc/images/SmallAdjacent.png and /dev/null differ
diff --git a/tests/FunctionalTests/selenium/doc/images/SmallEmbedded.png b/tests/FunctionalTests/selenium/doc/images/SmallEmbedded.png
deleted file mode 100644
index 399acbf5..00000000
Binary files a/tests/FunctionalTests/selenium/doc/images/SmallEmbedded.png and /dev/null differ
diff --git a/tests/FunctionalTests/selenium/doc/images/SmallStandalone.png b/tests/FunctionalTests/selenium/doc/images/SmallStandalone.png
deleted file mode 100644
index f04266a0..00000000
Binary files a/tests/FunctionalTests/selenium/doc/images/SmallStandalone.png and /dev/null differ
diff --git a/tests/FunctionalTests/selenium/doc/images/Standalone.png b/tests/FunctionalTests/selenium/doc/images/Standalone.png
deleted file mode 100644
index f9b670c0..00000000
Binary files a/tests/FunctionalTests/selenium/doc/images/Standalone.png and /dev/null differ
diff --git a/tests/FunctionalTests/selenium/doc/images/localhostAut.png b/tests/FunctionalTests/selenium/doc/images/localhostAut.png
deleted file mode 100644
index 25204654..00000000
Binary files a/tests/FunctionalTests/selenium/doc/images/localhostAut.png and /dev/null differ
diff --git a/tests/FunctionalTests/selenium/doc/images/localhostDriver.png b/tests/FunctionalTests/selenium/doc/images/localhostDriver.png
deleted file mode 100644
index a904d7d4..00000000
Binary files a/tests/FunctionalTests/selenium/doc/images/localhostDriver.png and /dev/null differ
diff --git a/tests/FunctionalTests/selenium/doc/images/localhostSelenium.png b/tests/FunctionalTests/selenium/doc/images/localhostSelenium.png
deleted file mode 100644
index af527be5..00000000
Binary files a/tests/FunctionalTests/selenium/doc/images/localhostSelenium.png and /dev/null differ
diff --git a/tests/FunctionalTests/selenium/doc/images/stockmeister.png b/tests/FunctionalTests/selenium/doc/images/stockmeister.png
deleted file mode 100644
index b07aabc6..00000000
Binary files a/tests/FunctionalTests/selenium/doc/images/stockmeister.png and /dev/null differ
diff --git a/tests/FunctionalTests/selenium/doc/images/tested-with-selenium.png b/tests/FunctionalTests/selenium/doc/images/tested-with-selenium.png
deleted file mode 100644
index fa80b414..00000000
Binary files a/tests/FunctionalTests/selenium/doc/images/tested-with-selenium.png and /dev/null differ
diff --git a/tests/FunctionalTests/selenium/doc/index.html b/tests/FunctionalTests/selenium/doc/index.html
deleted file mode 100644
index 8f7fed80..00000000
--- a/tests/FunctionalTests/selenium/doc/index.html
+++ /dev/null
@@ -1,30 +0,0 @@
-
-
-
-
- Selenium
-
-
-
JSRMI (Javascript Remote Method Invocation) is a portable browser-neutral Javascript library that makes it possible to execute
-Javascript functions in a browser from a process external to the browser.
-
JSRMI is not in any way tied to Java's RMI, but provides a similar mechanism. JSRMI is completely decoupled from the core Selenium Javascript API, but it can
-be used to access the Selenium API from outside the browser.
-
All of the
-browser-side JSRMI code resides in the rmi.js script - available in the Selenium
-distribution.
This will modify the text of a text area in the browser. Looks strangely
-familiar to Javascript doesn't it? You can of course call the selenium API too
-if the browser has loaded the main Selenium page (which also includes the rmi.js
-script - at least that is the plan - I hope (Aslak)).
-
How does it work?
-
(You can safely skip this section if you don't care - this is gory details)
-
Browser side
-
The rmi.js script uses the
-
-XMLHttpRequest object (available in all compatible browsers) to communicate
-with the external process. It executes a GET-POST loop which is repeated ad
-infinitum - pulling JSRMI invocations from the external process with GET and
-POSTing the results back. This all happens in a separate thread, thereby having
-minimal impact on the rest of the web page - without causing a page refresh.
-
The rmi.js script will do a HTTP GET to a URL on the same host/port as the rmi.js
-script was loaded from. The content returned from the GET (which must comply
-with the JSRMI protocol) is then translated into
-Javascript and dynamically executed via Javascript's
-eval() function.
-
The result of the function call (typically a Javascript object) is translated
-back into the JSRMI protocol format and POSTed back to the same URL as the GET.
-
External process side
-
The external process typically consists of a library that embeds the
-following functionality:
-
-
A HTTP server (should be light to ensure fast startup)
-
An API that translates local invocations into the JSRMI protocol
-
Two blocking queues:
-
-
Output queue - HTTP GET invocations will take JSRMI protocol strings
- (representing browser side invocations) from this queue and block until
- something is available. These strings are returned to the HTTP client (The
- rmi.js script in the browser). This means a blocking GET for the JSRMI
- browser side).
-
Input queue - HTTP POST data from the browser side JSRMI will be enqued
- here. This data represents results of browser side Javascript invocations.
-
-
-
A local invocation should translate the invocation to a JSRMI protocol string
-and put it on the output queue (which jsrmi will GET). It should then wait for
-the result of the browser side invocation to be put back on the input queue via
-a POST from jsrmi. Finally it should translate the return value (another JSRMI
-protocol string) into a native object and return it to the caller.
-
At any given point in time there should only be one single JSRMI protocol
-string in one of the queues - depending on the where the invocation is in its
-lifecycle.
-
Reference objects
-
JSRMI allows objects (such as browser side HTMLDocument, HTMLTextField etc)
-to be transferred back and forth. This is based on a simple mechanism where each
-object is given a unique id and maintained in a pool on each side. this pool is
-used to reference and dereference native objects back and forth from the JSRMI
-protocol strings.
-
Why would I use JSRMI?
-
With Selenium
-
The Selenium browser runtime will load both selenium test scripts and the web
-pages from the web application you're testing into the browser. Modern browsers
-don't allow content to be loaded from different hosts (cross browsing security
-restrictions). A web application being tested will typically be deployed on a
-server, and therefore the selenium test scripts must be loaded from the same web
-server. Depending on who's writing the Selenium scripts and executing them, this
-may or may not be a restriction to its usage.
-
Under some circumstances it is desirable to keep Selenium test scripts on
-your local machine (the same as the one running the browser with the Selenium
-runtime) rather than on a remote web server hosting the web application being
-tested. Some examples are:
-
-
The edit/run cycle of selenium scripts can be cumbersome if the script has
- to be deployed to a server each time it is modified. Being able to keep the
- scripts on a different machine (such as the one on your desk) can
- significantly improve the ease of use and rapid development of tests. JSRMI
- lets you do just that.
-
Putting in place a deployment routine for selenium script requires
- technical knowledge of the web application's build process as well as the web
- server hosting it. Many users of Selenium will not have easy access to this
- expertise. JSRMI lets these users use Selenium nevertheless.
-
-
It is important to emphasise that hosting the Selenium scripts on a local
-machine would also require that the browser loads the web site being tested from
-the local machine. Aren't we creating new problems by requiring testers to
-install a full web server environment on their machines? Actually no. The JSRMI
-libraries in Ruby and Java (and those who may follow) will soon provide a light
-HTTP proxy server. The local browser will load the remote web site through this
-HTTP proxy. The browser's security restrictions are satisfied since all content
-(Selenium runtime, Selenium scripts and the remote website) is loaded through
-localhost.
-
Scripting of existing web applications
-
Think of all boring web form tasks you could automate with JSRMI....
How do I implement a JSRMI client library for language X?
-
Start by understand the inner workings - look at the ruby implementation and
-study the javascript. (When the JSRMI protocol is better described, studying
-this code should not be necessary).
-
It will be to implement a JSRMI client
-library in a dynamic language than a static language, because dynamic languages
-allow arbitrary messages (method invocations) to be sent to an object. Most
-dynamic languages (Ruby, Python, Groovy, Smalltalk) have a generic mechanism to
-intercept any message and an object message->JSRMI protocol translation logic is
-trivial to implement based on this.
-
Guidelines for static languages such as Java and C#
-
JSRMI clients for static languages such as Java or C# will either have to
-choose a subset of the Javascript functions and objects that you want to access,
-or implement some generic invocation mechanism that allows raw JSRMI protocol
-strings.
-
The former is more easy to use from a user perspective, but will be
-restricted in terms of flexibility. The latter is completely generic, but
-awkward to deal with from a user perspective.
-
The recommendation is to implement a raw interface to the JSRMI protocol and
-have a generic dynamic proxy implementation on top of that. This way the API
-support can easily be extended simply by implementing new interfaces for the
-Javascript counterparts and generate dynamic proxies on the fly as needed.
-
Calling functions/methods in an external process from the browser using JSRMI
-
This is currently not possible.
-
-
\ No newline at end of file
diff --git a/tests/FunctionalTests/selenium/doc/release-notes.html b/tests/FunctionalTests/selenium/doc/release-notes.html
deleted file mode 100644
index f7b7971b..00000000
--- a/tests/FunctionalTests/selenium/doc/release-notes.html
+++ /dev/null
@@ -1,97 +0,0 @@
-
-
-
- Release Notes
-
-
-
-
-
-Release information for different distributions of Selenium
-
-
Selenium 0.6.0
-
-September 24, 2005
-
-
-
pattern-matching
Support for regular-expression and exact matching. Allow patterns to be used to match alert and confirmation messages.
-
support for Javascript prompts
Capture and verify prompt-messages, set up return values.
A command is what tells Selenium what to do. Selenium commands come in two 'flavors', Actions and Assertions.
-Each command call is one line in the test table of the form:
-
-
-
-
-
-
-
-
-
command
-
target
-
value
-
-
-
-
-
Actions are commands that generally manipulate the state of the application. They do things like "click this link" and "select that option". If an Action fails, or has an error, the execution of the current test is stopped.
-
Checks verify the state of the application conforms to what is expected. Examples include "make sure the page title is X" and "check that this checkbox is checked". It is possible to tell Selenium to stop the test when an Assertion fails, or to simply record the failure and continue.
-
Element Locators tell Selenium which HTML element a command refers to. Many commands require an Element Locator as the "target" attribute. Examples of Element Locators include "elementId" and "document.forms[0].element". These are described more clearly in the next section.
-
Patterns are used for various reasons, e.g. to specify the expected value of an input field, or identify a select option. Selenium supports various types of pattern, including regular-expressions, all of which are described in more detail below.
Select Option Specifiers provide different ways of specifying options of an HTML Select element (e.g. for selecting a specific option, or for asserting that the selected option satisfies a specification). There are several forms of Select Option Specifier.
-
-
label=labelPattern
-
-
matches options based on their labels, i.e. the visible text.
-
-
label=regexp:^[Oo]ther
-
-
-
-
-
value=valuePattern
-
-
matches options based on their values.
-
-
value=other
-
-
-
-
-
id=id
-
-
matches options based on their ids.
-
-
id=option1
-
-
-
-
-
index=index
-
-
matches an option based on its index (offset from zero).
-
-
index=2
-
-
-
-
-
-
Without a prefix, the default behaviour is to only match on labels.
Various Pattern syntaxes are available for matching string values:
-
-
glob:pattern
-
Match a string against a "glob" (aka "wildmat") pattern. "Glob" is a kind of limited regular-expression syntax typically used in command-line shells. In a glob pattern, "*" represents any sequence of characters, and "?" represents any single character. Glob patterns match against the entire string.
-
regexp:regexp
-
Match a string using a regular-expression. The full power of JavaScript regular-expressions is available.
-
exact:string
-
Match a string exactly, verbatim, without any of that fancy wildcard stuff.
-
-
If no pattern prefix is specified, Selenium assumes that it's a "glob" pattern.
Actions tell Selenium to do something in the application. They generally represent something a user would do.
-
Many Actions can be called with the "AndWait" suffix. This suffix tells Selenium that the action will cause the browser to make a call to the server, and that Selenium should wait for a new page to load.
-The exceptions to this pattern are the "open" and "click" actions, which will both wait for a page to load by default.
-
open( url )
-
-
Opens a URL in the test frame. This accepts both relative and absolute URLs.
-
Note: The URL must be on the same site as Selenium due to security restrictions in the browser (Cross Site Scripting).
Clicks on a link, button, checkbox or radio button.
-If the click action causes a new page to load (like a link usually does), use "clickAndWait".
-
examples:
-
-
-
-
-
-
-
-
-
click
-
aCheckbox
-
-
-
clickAndWait
-
submitButton
-
-
-
clickAndWait
-
anyLink
-
-
-
-
-
-
-
note:
-
Selenium will always automatically click on a popup dialog raised by the alert() or confirm()
-methods. (The exception is those raised during 'onload', which are not yet handled by Selenium).
-You must use [verify|assert]Alert or [verify|assert]Confirmation to tell Selenium that you expect the
-popup dialog. You may use chooseCancelOnNextConfirmation to click 'cancel' on the next confirmation
-dialog instead of clicking 'OK'.
-
-
-
type( inputLocator, value )
-
-
Sets the value of an input field, as though you typed it in.
-
Can also be used to set the value of combo boxes, check boxes, etc. In these cases, value should be the value of the option selected, not the visible text.
-
examples:
-
-
-
-
-
-
-
-
-
type
-
nameField
-
John Smith
-
-
typeAndWait
-
textBoxThatSubmitsOnChange
-
newValue
-
-
-
-
-
-
select( dropDownLocator, optionSpecifier )
-
-
Select an option from a drop-down, based on the optionSpecifier. If more than one option matches the specifier (e.g. due to the use of globs like "f*b*", or due to more than one option having the same label or value), then the first matches is selected.
-
examples:
-
-
-
-
-
-
-
-
-
select
-
dropDown
-
Australian Dollars
-
-
select
-
dropDown
-
index=0
-
-
selectAndWait
-
currencySelector
-
value=AUD
-
-
selectAndWait
-
currencySelector
-
label=Aus*lian D*rs
-
-
-
-
-
-
selectWindow( windowId )
-
-
Selects a popup window. Once a popup window has been selected, all commands go to that window. To select the main window again, use "null" as the target.
-
target: The id of the window to select.
-
value:ignored
-
examples:
-
-
-
-
-
-
-
-
-
selectWindow
-
myPopupWindow
-
-
-
selectWindow
-
null
-
-
-
-
-
-
-
goBack()
-
-
Simulates the user clicking the "back" button on their browser.
-
examples:
-
-
-
-
-
-
-
-
-
goBack
-
-
-
-
-
-
-
-
close()
-
-
Simulates the user clicking the "close" button in the titlebar of a popup window.
-
examples:
-
-
-
-
-
-
-
-
-
close
-
-
-
-
-
-
-
-
pause( milliseconds )
-
-
Pauses the execution of the test script for a specified amount of time. This is useful for debugging a script or pausing to wait for some server side action.
-
examples:
-
-
-
-
-
-
-
-
-
pause
-
5000
-
-
-
pause
-
2000
-
-
-
-
-
-
-
fireEvent( elementLocator, eventName )
-
-
Explicitly simulate an event, to trigger the corresponding "onevent" handler.
-
examples:
-
-
-
-
-
-
-
-
-
fireEvent
-
textField
-
focus
-
-
fireEvent
-
dropDown
-
blur
-
-
-
-
-
-
waitForValue( inputLocator, value )
-
-
Waits for a specified input (e.g. a hidden field) to have a specified value. Will succeed immediately if the input already has the value. This is implemented by polling for the value. Warning: can block indefinitely if the input never has the specified value.
-
example:
-
-
-
-
-
-
-
-
-
waitForValue
-
finishIndication
-
isfinished
-
-
-
-
-
-
store( valueToStore, variableName )
-
-
Stores a value into a variable. The value can be constructed using either variable substitution or javascript evaluation, as detailed in 'Parameter construction and Variables' (below).
-
examples:
-
-
-
-
-
-
-
-
-
store
-
Mr John Smith
-
fullname
-
-
store
-
${title} ${firstname} ${surname}
-
fullname
-
-
store
-
javascript{Math.round(Math.PI * 100) / 100}
-
PI
-
-
-
-
-
-
storeValue( inputLocator, variableName )
-
-
Stores the value of an input field into a variable.
Stores the value of an element attribute into a variable.
-
examples:
-
-
-
-
-
-
-
-
-
storeAttribute
-
input1@class
-
classOfInput1
-
-
verifyAttribute
-
input2@class
-
${classOfInput1}
-
-
-
-
-
-
chooseCancelOnNextConfirmation()
-
-
Instructs Selenium to click Cancel on the next javascript confirmation dialog to be raised. By default, the confirm function will return true, having the same effect as manually clicking OK. After running this command, the next confirmation will behave as if the user had clicked Cancel.
-
examples:
-
-
-
-
-
-
-
-
-
chooseCancelOnNextConfirmation
-
-
-
-
-
-
-
-
answerOnNextPrompt( answerString )
-
-
Instructs Selenium to return the specified answerString in response to the next prompt.
Checks are used to verify the state of the application. They can be used to check the value of a form field, the presense of some text, or the URL of the current page.
-
All Selenium Checks can be used in 2 modes, "assert" and "verify". These behave identically, except that when an "assert" check fails, the test is aborted. When a "verify" check fails, the test will continue execution.
-This allows a single "assert" to ensure that the application is on the correct page, followed by a bunch of "verify" checks to test form field values, labels, etc.
-
assertLocation( relativeLocation )
-
-
examples:
-
-
-
-
-
-
-
-
-
verifyLocation
-
/mypage
-
-
-
assertLocation
-
/mypage
-
-
-
-
-
-
-
assertTitle( titlePattern )
-
-
Verifies the title of the current page.
-
examples:
-
-
-
-
-
-
-
-
-
verifyTitle
-
My Page
-
-
-
assertTitle
-
My Page
-
-
-
-
-
-
-
assertValue( inputLocator, valuePattern )
-
-
Verifies the value of an input field (or anything else with a value parameter). For checkbox/radio elements, the value will be "on" or "off" depending on whether the element is checked or not.
-
examples:
-
-
-
-
-
-
-
-
-
verifyValue
-
nameField
-
John Smith
-
-
assertValue
-
document.forms[2].nameField
-
John Smith
-
-
-
-
-
-
assertSelected( selectLocator, optionSpecifier )
-
-
Verifies that the selected option of a drop-down satisfies the optionSpecifier.
Verifies the labels of all options in a drop-down against a comma-separated list. Commas in an expected option can be escaped as ",".
-
examples:
-
-
-
-
-
-
-
-
-
verifySelectOptions
-
dropdown2
-
John Smith,Dave Bird
-
-
assertSelectOptions
-
document.forms[2].dropDown
-
Smith\, J,Bird\, D
-
-
-
-
-
-
assertText( elementLocator, textPattern )
-
-
Verifies the text of an element. This works for any element that contains text. This command uses either the textContent (Mozilla-like browsers) or the innerText (IE-like browsers) of the element, which is the rendered text shown to the user.
Verifies that the specified text appears somewhere on the rendered page shown to the user.
-
examples:
-
-
-
-
-
-
-
-
-
verifyTextPresent
-
You are now logged in.
-
-
-
assertTextPresent
-
You are now logged in.
-
-
-
-
-
-
-
assertTextNotPresent( text )
-
-Verifies that the specified text does NOT appear anywhere on the rendered page.
-
assertElementPresent( elementLocator )
-
-
Verifies that the specified element is somewhere on the page.
-
examples:
-
-
-
-
-
-
-
-
-
verifyElementPresent
-
submitButton
-
-
-
assertElementPresent
-
//img[@alt='foo']
-
-
-
-
-
-
-
assertElementNotPresent( elementLocator )
-
-
Verifies that the specified element is NOT on the page.
-
examples:
-
-
-
-
-
-
-
-
-
verifyElementNotPresent
-
cancelButton
-
-
-
assertElementNotPresent
-
cancelButton
-
-
-
-
-
-
-
assertTable( cellAddress, valuePattern )
-
-
Verifies the text in a cell of a table. The cellAddress syntax tableName.row.column, where row and column start at 0.
-
examples:
-
-
-
-
-
-
-
-
-
verifyTable
-
myTable.1.6
-
Submitted
-
-
assertTable
-
results.0.2
-
13
-
-
-
-
-
-
assertVisible( elementLocator )
-
-
Verifies that the specified element is both present and visible. An element can be rendered invisible by setting the CSS "visibility" property to "hidden", or the "display" property to "none", either for the element itself or one if its ancestors.
-
examples:
-
-
-
-
-
-
-
-
-
verifyVisible
-
postcode
-
-
-
assertVisible
-
postcode
-
-
-
-
-
-
-
assertNotVisible( elementLocator )
-
-
Verifies that the specified element is NOT visible. Elements that are simply not present are also considered invisible.
-
examples:
-
-
-
-
-
-
-
-
-
verifyNotVisible
-
postcode
-
-
-
assertNotVisible
-
postcode
-
-
-
-
-
-
-
verifyEditable / assertEditable( inputLocator )
-
-
Verifies that the specified element is editable, ie. it's an input element, and hasn't been disabled.
-
examples:
-
-
-
-
-
-
-
-
-
verifyEditable
-
shape
-
-
-
assertEditable
-
colour
-
-
-
-
-
-
-
assertNotEditable( inputLocator )
-
-Verifies that the specified element is NOT editable, ie. it's NOT an input element, or has been disabled.
-
assertAlert( messagePattern )
-
-
Verifies that a javascript alert with the specified message was generated. Alerts must be verified in the same order that they were generated.
-
Verifying an alert has the same effect as manually clicking OK. If an alert is generated but you do not verify it, the next Selenium action will fail.
-
NOTE: under Selenium, javascript alerts will NOT pop up a visible alert dialog.
-
NOTE: Selenium does NOT support javascript alerts that are generated in a page's onload() event handler. In this case a visible dialog WILL be generated and Selenium will hang until you manually click OK.
-
examples:
-
-
-
-
-
-
-
-
-
verifyAlert
-
Invalid Phone Number
-
-
-
assertAlert
-
Invalid Phone Number
-
-
-
-
-
-
-
assertConfirmation( messagePattern )
-
-
Verifies that a javascript confirmation dialog with the specified message was generated. Like alerts, confirmations must be verified in the same order that they were generated.
-
By default, the confirm function will return true, having the same effect as manually clicking OK. This can be changed by prior execution of the chooseCancelOnNextConfirmation command (see above). If an confirmation is generated but you do not verify it, the next Selenium action will fail.
-
NOTE: under Selenium, javascript confirmations will NOT pop up a visible dialog.
-
NOTE: Selenium does NOT support javascript confirmations that are generated in a page's onload() event handler. In this case a visible dialog WILL be generated and Selenium will hang until you manually click OK.
-
examples:
-
-
-
-
-
-
-
-
-
assertConfirmation
-
Remove this user?
-
-
-
verifyConfirmation
-
Are you sure?
-
-
-
-
-
-
-
assertPrompt( messagePattern )
-
-
Verifies that a javascript prompt dialog with the specified message was generated. Like alerts, prompts must be verified in the same order that they were generated.
-
Successful handling of the prompt requires prior execution of the answerOnNextPrompt command (see above). If a prompt is generated but you do not verify it, the next Selenium action will fail.
All Selenium command parameters can be constructed using both simple
-variable substitution as well as full javascript. Both of these
-mechanisms can access previously stored variables, but do so using
-different syntax.
-
Stored Variables
-
The commands store, storeValue and storeText can be used to store a variable
-value for later access. Internally, these variables are stored in a map called "storedVars",
-with values keyed by the variable name. These commands are documented in the command reference.
-
Variable substitution
-
Variable substitution provides a simple way to include a previously stored variable in a
-command parameter. This is a simple mechanism, by which the variable to substitute is indicated
-by ${variableName}. Multiple variables can be substituted, and intermixed with static text.
-
Example:
-
-
-
-
-
-
-
-
-
store
-
Mr
-
title
-
-
storeValue
-
nameField
-
surname
-
-
store
-
${title} ${surname}
-
fullname
-
-
type
-
textElement
-
Full name is: ${fullname}
-
-
-
-
-
Javascript evaluation
-
Javascript evaluation provides the full power of javascript in constructing a command parameter.
-To use this mechanism, the entire parameter value must be prefixed by
-'javascript{' with a trailing '}'. The text inside the braces is evaluated as a javascript expression,
-and can access previously stored variables using the storedVars map detailed above.
-Note that variable substitution cannot be combined with javascript evaluation.
It can be quite simple to extend Selenium, adding your own actions, checks and locator-strategies.
-This is done with javascript by adding methods to the Selenium object prototype, and the PageBot
-object prototype. On startup, Selenium will automatically look through methods on these prototypes,
-using name patterns to recognise which ones are actions, checks and locators.
-
The following examples try to give an indication of how Selenium can be extended with javascript.
-
-
Actions
-
-
All doFoo methods on the Selenium prototype are added as actions. For each action foo there
-is also an action fooAndWait registered. An action method can take up to 2 parameters, which
-will be passed the second and third column values in the test.
-
Example: Add a "typeRepeated" action to Selenium, which types the text twice into a text box.
-
-Selenium.prototype.doTypeRepeated = function(locator, text) {
- // All locator-strategies are automatically handled by "findElement"
- var element = this.page().findElement(locator);
-
- // Create the text to type
- var valueToType = text + text;
-
- // Replace the element text with the new text
- this.page().replaceText(element, valueToType);
-};
-
-
-
Checks
-
-
All assertFoo methods on the Selenium prototype are added as checks. For each check foo there
-is an assertFoo and verifyFoo registered. An assert method can take up to 2 parameters, which
-will be passed the second and third column values in the test.
-
Example: Add a valueRepeated check, that makes sure that the element value
-consists of the supplied text repeated. The 2 commands that would be available in tests would be
-assertValueRepeated and verifyValueRepeated.
-
-Selenium.prototype.assertValueRepeated = function(locator, text) {
- // All locator-strategies are automatically handled by "findElement"
- var element = this.page().findElement(locator);
-
- // Create the text to verify
- var expectedValue = text + text;
-
- // Get the actual element value
- var actualValue = element.value;
-
- // Make sure the actual value matches the expected
- this.assertMatches(expectedValue, actualValue);
-};
-
-
-
Locator Strategies
-
-
All locateElementByFoo methods on the PageBot prototype are added as locator-strategies. A locator strategy takes 2 parameters, the first being the locator string (minus the prefix), and the second being the document in which to search.
-
Example: Add a "valuerepeated=" locator, that finds the first element a value attribute equal to the the supplied value repeated.
-
-// The "inDocument" is a the document you are searching.
-PageBot.prototype.locateElementByValueRepeated = function(text, inDocument) {
- // Create the text to search for
- var expectedValue = text + text;
-
- // Loop through all elements, looking for ones that have
- // a value === our expected value
- var allElements = inDocument.getElementsByTagName("*");
- for (var i = 0; i < allElements.length; i++) {
- var testElement = allElements[i];
- if (testElement.value && testElement.value === expectedValue) {
- return testElement;
- }
- }
- return null;
-};
-
-
-
user-extensions.js
-
-
By default, Selenium looks for a file called "user-extensions.js", and loads the javascript code found in that file. This file provides a convenient location for adding features to Selenium, without needing to modify the core Selenium sources.
-
In the standard distibution, this file does not exist. Users can create this file and place their extension code in this common location, removing the need to modify the Selenium sources, and hopefully assisting with the upgrade process.
-
-
-
:
-
-
-
-
diff --git a/tests/FunctionalTests/selenium/doc/seleniumReference.txt b/tests/FunctionalTests/selenium/doc/seleniumReference.txt
deleted file mode 100644
index e7819869..00000000
--- a/tests/FunctionalTests/selenium/doc/seleniumReference.txt
+++ /dev/null
@@ -1,771 +0,0 @@
-=========================
-Selenium Reference
-=========================
-
---------
-Concepts
---------
-
- A **command** is what tells Selenium what to do. Selenium commands come in two 'flavors', **Actions** and **Assertions**.
- Each command call is one line in the test table of the form:
-
- ======= ====== =====
- command target value
- ======= ====== =====
-
- **Actions** are commands that generally manipulate the state of the application. They do things like "click this link" and "select that option". If an Action fails, or has an error, the execution of the current test is stopped.
-
- **Assertions** verify the state of the application conforms to what is expected. Examples include "make sure the page title is X" and "verify that this checkbox is checked". It is possible to tell Selenium to stop the test when an Assertion fails, or to simply record the failure and continue.
-
- **Element Locators** tell Selenium which HTML element a command refers to. Many commands require an Element Locator as the "target" attribute. Examples of Element Locators include "elementId" and "document.forms[0].element". These are described more clearly in the next section.
-
- **Patterns** are used for various reasons, e.g. to specify the expected value of an input field, or identify a select option. Selenium supports various types of pattern, including regular-expressions, all of which are described in more detail below.
-
------------------
-Element Locators
------------------
-
- Element Locators allow Selenium to identify which HTML element a
- command refers to. The format of a locator is:
-
- *locatorType*\ **=**\ *argument*
-
- We support the following strategies for locating
- elements:
-
- **id=**\ *id*
-
- Select the element with the specified @id attribute.
-
- **name=**\ *name*
-
- Select the first element with the specified @name attribute.
- - username
- - name=username
-
- The name may optionally be following by one or more *element-filters*, separated from the name by whitespace. If the *filterType* is not specified, **value** is assumed.
- - name=flavour value=chocolate
-
- **identifier=**\ *id*
-
- Select the element with the specified @id attribute. If no match is found, select the first element whose @name attribute is *id*.
-
- **dom=**\ *javascriptExpression*
-
- Find an element using JavaScript traversal of the HTML Document Object Model. DOM locators *must* begin with "document.".
- - dom=document.forms['myForm'].myDropdown
- - dom=document.images[56]
-
- **xpath=**\ *xpathExpression*
-
- Locate an element using an XPath expression.
- - xpath=//img[@alt='The image alt text']
- - xpath=//table[@id='table1']//tr[4]/td[2]
-
- **link=**\ *textPattern*
-
- Select the link (anchor) element which contains text matching the specified *pattern*.
- - link=The link text
-
-
- If no *locatorType* is specified, Selenium uses:
-
- * **dom**, for locators starting with "document."
- * **xpath**, for locators starting with "//"
- * **identifier**, otherwise
-
----------------
-Element Filters
----------------
-
- Element filters can be used with a locator to refine a list of candidate elements. They are currently used only in the 'name' element-locator.
-
- Filters look much like locators, ie.
-
- *filterType*\ **=**\ *argument*
-
- Supported element-filters are:
-
- **value=**\ *valuePattern*
-
- Matches elements based on their values. This is particularly useful for refining a list of similarly-named toggle-buttons.
-
- **index=**\ *index*
-
- Selects a single element based on its position in the list offset from zero).
-
-------------------------
-Select Option Specifiers
-------------------------
-
- Select Option Specifiers provide different ways of specifying options of an HTML Select element (e.g. for selecting a specific option, or for asserting that the selected option satisfies a specification). There are several forms of Select Option Specifier.
-
- **label=**\ *labelPattern*
- matches options based on their labels, i.e. the visible text.
- - label=regexp:^[Oo]ther
-
- **value=**\ *valuePattern*
- matches options based on their values.
- - value=other
-
- **id=**\ *id*
- matches options based on their ids.
- - id=option1
-
- **index=**\ *index*
- matches an option based on its index (offset from zero).
- - index=2
-
- If no optionSpecifierType prefix is provided, the default behaviour is to match on **label**.
-
-------------------------
-String-match Patterns
-------------------------
-
- Various Pattern syntaxes are available for matching string values:
-
- **glob:**\ *pattern*
- Match a string against a "glob" (aka "wildmat") pattern. "Glob" is a kind of limited regular-expression syntax typically used in command-line shells. In a glob pattern, "*" represents any sequence of characters, and "?" represents any single character. Glob patterns match against the entire string.
-
- **regexp:**\ *regexp*
- Match a string using a regular-expression. The full power of JavaScript regular-expressions is available.
-
- **exact:**\ *string*
- Match a string exactly, verbatim, without any of that fancy wildcard stuff.
-
- If no pattern prefix is specified, Selenium assumes that it's a "glob" pattern.
-
-----------------
-Selenium Actions
-----------------
-
- Actions tell Selenium to do something in the application. They generally represent something a user would do.
-
- Many **Actions** can be called with the "AndWait" suffix. This suffix tells Selenium that the action will cause the browser to make a call to the server, and that Selenium should wait for a new page to load.
-
- **open**\ ( *url* )
-
- Opens a URL in the test frame. This accepts both relative and absolute URLs.
-
- The "open" command waits for the page to load before proceeding,
- ie. the "AndWait" suffix is implicit.
-
- *Note*: The URL must be on the same site as Selenium due to security restrictions in the browser (Cross Site Scripting).
-
- **examples:**
-
- ==== ================= =====
- open /mypage
- open http://localhost/
- ==== ================= =====
-
- **click**\ ( *elementLocator* )
-
- Clicks on a link, button, checkbox or radio button.
- If the click action causes a new page to load (like a link usually does), use "clickAndWait".
-
- **examples:**
-
- ============ ================== =====
- click aCheckbox
- clickAndWait submitButton
- clickAndWait anyLink
- ============ ================== =====
-
- **type**\ ( *inputLocator*, *value* )
-
- Sets the *value* of an input field, as though you typed it in.
-
- Can also be used to set the value of combo boxes, check boxes, etc. In these cases, *value* should be the value of the option selected, not the visible text.
-
- **examples:**
-
- =========== ========================== ==========
- type nameField John Smith
- typeAndWait textBoxThatSubmitsOnChange newValue
- =========== ========================== ==========
-
- **select**\ ( *dropDownLocator*, *optionSpecifier* )
-
- Select an option from a drop-down, based on the *optionSpecifier*. If more than one option matches the specifier (e.g. due to the use of globs like "f*b*", or due to more than one option having the same label or value), then the first matches is selected.
-
- **examples:**
-
- ============= ================ ==========
- select dropDown Australian Dollars
- select dropDown index=0
- selectAndWait currencySelector value=AUD
- selectAndWait currencySelector label=Aus*lian D*rs
- ============= ================ ==========
-
- **check**\ ( *toggleButtonLocator* )
-
- Check a toggle-button (ie. a check-box or radio-button).
-
- Note: if addressing the toggle-button element by name, you'll need to append an element-filter (e.g. typically by value), since toggle-button groups consist of input-elements with the same name.
-
- **examples:**
-
- ============= ======================== ==========
- check name=flavour value=honey
- check flavour honey
- ============= ======================== ==========
-
- **uncheck**\ ( *toggleButtonLocator* )
-
- Un-check a toggle-button.
-
- **selectWindow**\ ( *windowId* )
-
- Selects a popup window. Once a popup window has been selected, all commands go to that window. To select the main window again, use "null" as the target.
-
- **target:** The id of the window to select.
-
- **value:** *ignored*
-
- **examples:**
-
- ============ ============= =====
- selectWindow myPopupWindow
- selectWindow null
- ============ ============= =====
-
- **goBack**\ ()
-
- Simulates the user clicking the "back" button on their browser.
-
- **examples:**
-
- ============= ==== =====
- goBackAndWait
- ============= ==== =====
-
- **close**\ ()
-
- Simulates the user clicking the "close" button in the titlebar of a popup window.
-
- **examples:**
-
- ====== ==== =====
- close
- ====== ==== =====
-
- **pause**\ ( *milliseconds* )
-
- Pauses the execution of the test script for a specified amount of time. This is useful for debugging a script or pausing to wait for some server side action.
-
- **examples:**
-
- ===== ==== =====
- pause 5000
- pause 2000
- ===== ==== =====
-
- **fireEvent**\ ( *elementLocator*, *eventName* )
-
- Explicitly simulate an event, to trigger the corresponding "on\ *event*" handler.
-
- **examples:**
-
- ========= =========== ========
- fireEvent textField focus
- fireEvent dropDown blur
- ========= =========== ========
-
- **waitForValue**\ ( *inputLocator*, *value* )
-
- Waits for a specified input (e.g. a hidden field) to have a specified *value*. Will succeed immediately if the input already has the value. This is implemented by polling for the value. Warning: can block indefinitely if the input never has the specified value.
-
- **example:**
-
- ============ ================ ==========
- waitForValue finishIndication isfinished
- ============ ================ ==========
-
- **store**\ ( *valueToStore*, *variableName* )
-
- Stores a value into a variable. The value can be constructed using either variable substitution or JavaScript evaluation, as detailed in 'Parameter construction and Variables' (below).
-
- **examples:**
-
- ========== ============================================ =========
- store Mr John Smith fullname
- store ${title} ${firstname} ${surname} fullname
- store javascript{Math.round(Math.PI * 100) / 100} PI
- ========== ============================================ =========
-
- **storeValue**\ ( *inputLocator*, *variableName* )
-
- Stores the value of an input field into a variable.
-
- **examples:**
-
- ========== ========= =========
- storeValue userName userID
- type userName ${userID}
- ========== ========= =========
-
- **storeText**\ ( *elementLocator*, *variableName* )
-
- Stores the text of an element into a variable.
-
- **examples:**
-
- =========== =========== ====================
- storeText currentDate expectedStartDate
- verifyValue startDate ${expectedStartDate}
- =========== =========== ====================
-
- **storeAttribute**\ ( *elementLocator*\ @\ *attributeName*, *variableName* )
-
- Stores the value of an element attribute into a variable.
-
- **examples:**
-
- =============== ============== ====================
- storeAttribute input1@\ class classOfInput1
- verifyAttribute input2@\ class ${classOfInput1}
- =============== ============== ====================
-
- **chooseCancelOnNextConfirmation**\ ()
-
- By default, Selenium's overridden window.confirm() function will
- return true, as if the user had manually clicked OK. After running
- this command, the next call to confirm() will return false, as if
- the user had clicked Cancel.
-
- **examples:**
-
- ============================== ===== =====
- chooseCancelOnNextConfirmation
- ============================== ===== =====
-
- **answerOnNextPrompt**\ ( *answerString* )
-
- Instructs Selenium to return the specified *answerString* in
- response to the next call to window.prompt().
-
- **examples:**
-
- ========================== ========= =====
- answerOnNextPrompt Kangaroo
- ========================== ========= =====
-
--------------------
-Selenium Assertions
--------------------
-
- Assertions are used to verify the state of the application. They can be used to check the value of a form field, the presense of some text, or the URL of the current page.
-
- All Selenium assertions can be used in 2 modes, "assert" and "verify". These behave identically, except that when an "assert" fails, the test is aborted. When a "verify" fails, the test will continue execution. This allows a single "assert" to ensure that the application is on the correct page, followed by a bunch of "verify" assertions to test form field values, labels, etc.
-
- A growing number of assertions have a negative version. In most cases, except where indicated, if the positive assertion is of the form **assertXYZ**, then the negative cases will be of the form **assertNotXYZ**.
-
- **assertLocation**\ ( *relativeLocation* )
-
- **examples:**
-
- ============== ======= =====
- verifyLocation /mypage
- assertLocation /mypage
- ============== ======= =====
-
- **assertTitle**\ ( *titlePattern* )
-
- Verifies the title of the current page.
-
- **examples:**
-
- =========== ======= =====
- verifyTitle My Page
- assertTitle My Page
- =========== ======= =====
-
- **assertNotTitle**\ ( *titlePattern* )
-
- Verifies that the title of the current page does not match the specified pattern.
-
- **assertValue**\ ( *inputLocator*, *valuePattern* )
-
- Verifies the value of an input field (or anything else with a value parameter). For checkbox/radio elements, the value will be "on" or "off" depending on whether the element is checked or not.
-
- **examples:**
-
- =========== =========================== ==========
- verifyValue nameField John Smith
- assertValue document.forms[2].nameField John Smith
- =========== =========================== ==========
-
- **assertNotValue**\ ( *inputLocator*, *valuePattern* )
-
- Verifies the value of an input field does not match the specified pattern.
-
- **assertSelected**\ ( *selectLocator*, *optionSpecifier* )
-
- Verifies that the selected option of a drop-down satisfies the *optionSpecifier*.
-
- **examples:**
-
- ============== =========================== ==========
- verifySelected dropdown2 John Smith
- verifySelected dropdown2 value=js*123
- assertSelected document.forms[2].dropDown label=J* Smith
- assertSelected document.forms[2].dropDown index=0
- ============== =========================== ==========
-
- **assertSelectOptions**\ ( *selectLocator*, *optionLabelList* )
-
- Verifies the labels of all options in a drop-down against a comma-separated list. Commas in an expected option can be escaped as "\,".
-
- **examples:**
-
- =================== =========================== ====================
- verifySelectOptions dropdown2 John Smith,Dave Bird
- assertSelectOptions document.forms[2].dropDown Smith\\, J,Bird\\, D
- =================== =========================== ====================
-
- **assertChecked**\ ( *toggleButtonLocator* )
-
- Verifies that the specified toggle-button element is checked.
-
- **examples:**
-
- ============= ======================== ==========
- verifyChecked flavour honey
- ============= ======================== ==========
-
- **assertText**\ ( *elementLocator*, *textPattern* )
-
- Verifies the text of an element. This works for any element that contains text. This command uses either the textContent (Mozilla-like browsers) or the innerText (IE-like browsers) of the element, which is the rendered text shown to the user.
-
- **examples:**
-
- ========== ==================== ==========
- verifyText statusMessage Successful
- assertText //div[@id='foo']//h1 Successful
- ========== ==================== ==========
-
- **assertNotText**\ ( *elementLocator*, *textPattern* )
-
- Verifies that the text of an element does not match the specified pattern.
-
- **assertAttribute**\ ( *elementLocator*\ @\ *attributeName*, *valuePattern* )
-
- Verifies the value of an element attribute.
-
- **examples:**
-
- =============== ====================== ==========
- verifyAttribute txt1@\ class bigAndBold
- assertAttribute document.images[0]@alt alt-text
- verifyAttribute //img[@id='foo']/@alt alt-text
- =============== ====================== ==========
-
- **assertNotAttribute**\ ( *elementLocator*\ @\ *attributeName*, *valuePattern* )
-
- Verifies that the value of an element attribute does not match the specified pattern.
-
- **assertTextPresent**\ ( *text* )
-
- Verifies that the specified text appears somewhere on the rendered page shown to the user.
-
- **examples:**
-
- ================= ====================== =====
- verifyTextPresent You are now logged in.
- assertTextPresent You are now logged in.
- ================= ====================== =====
-
- **assertTextNotPresent**\ ( *text* )
-
- Verifies that the specified text does NOT appear anywhere on the rendered page.
-
- **assertElementPresent**\ ( *elementLocator* )
-
- Verifies that the specified element is somewhere on the page.
-
- **examples:**
-
- ==================== ================= =====
- verifyElementPresent submitButton
- assertElementPresent //img[@alt='foo']
- ==================== ================= =====
-
- **assertElementNotPresent**\ ( *elementLocator* )
-
- Verifies that the specified element is NOT on the page.
-
- **examples:**
-
- ======================= ============ =====
- verifyElementNotPresent cancelButton
- assertElementNotPresent cancelButton
- ======================= ============ =====
-
- **assertTable**\( *cellAddress*, *valuePattern* )
-
- Verifies the text in a cell of a table. The *cellAddress* syntax *tableName.row.column*, where row and column start at 0.
-
- **examples:**
-
- =========== =========== =========
- verifyTable myTable.1.6 Submitted
- assertTable results.0.2 13
- =========== =========== =========
-
- **assertNotTable**\( *cellAddress*, *valuePattern* )
-
- Verifies that the text in a cell of a table does not match the specified pattern. Note that this will fail if the table cell does not exist.
-
- **assertVisible**\ ( *elementLocator* )
-
- Verifies that the specified element is both present *and* visible. An element can be rendered invisible by setting the CSS "visibility" property to "hidden", or the "display" property to "none", either for the element itself or one if its ancestors.
-
- **examples:**
-
- ============= ======== =====
- verifyVisible postcode
- assertVisible postcode
- ============= ======== =====
-
- **assertNotVisible**\ ( *elementLocator* )
-
- Verifies that the specified element is NOT visible. Elements that are simply not present are also considered invisible.
-
- **examples:**
-
- ================ ======== =====
- verifyNotVisible postcode
- assertNotVisible postcode
- ================ ======== =====
-
- **verifyEditable / assertEditable**\ ( *inputLocator* )
-
- Verifies that the specified element is editable, ie. it's an input element, and hasn't been disabled.
-
- **examples:**
-
- ============== ======== =====
- verifyEditable shape
- assertEditable colour
- ============== ======== =====
-
- **assertNotEditable**\ ( *inputLocator* )
-
- Verifies that the specified element is NOT editable, ie. it's NOT an input element, or has been disabled.
-
- **assertAlert**\ ( *messagePattern* )
-
- Verifies that a JavaScript alert was generated, with the specified
- message.
-
- If an alert is generated but you do not verify it, the next
- Selenium action will fail. Alerts must be verified in the order
- that they were generated.
-
- **examples:**
-
- ============== ==================== =====
- verifyAlert Invalid Phone Number
- assertAlert Invalid Phone Number
- ============== ==================== =====
-
- **assertConfirmation**\ ( *messagePattern* )
-
- Verifies that a JavaScript confirmation dialog was generated, with
- the specified message.
-
- By default, the confirm function will return true, having the same
- effect as manually clicking OK. This can be changed by prior
- execution of the **chooseCancelOnNextConfirmation** command (see
- above).
-
- Like alerts, any unexpected confirmation will cause the test to
- fail, and confirmations must be verified in the order that they
- were generated.
-
- **examples:**
-
- ================== ==================== =====
- assertConfirmation Remove this user?
- verifyConfirmation Are you sure?
- ================== ==================== =====
-
- **assertPrompt**\ ( *messagePattern* )
-
- Verifies that a JavaScript prompt dialog was generated, with the
- specified message.
-
- Successful handling of the prompt requires prior execution of the
- **answerOnNextPrompt** command (see above).
-
- Like alerts, unexpected prompts will cause the test to fail, and
- they must be verified in the order that they were generated.
-
- **examples:**
-
- ================== ============================= =====
- answerOnNextPrompt Joe
- click id=delegate
- verifyPrompt Delegate to who?
- ================== ============================= =====
-
--------------------------------------------
-Handling of alert(), confirm() and prompt()
--------------------------------------------
-
- Selenium overrides the default implementations of the JavaScript
- window.alert(), window.confirm() and window.prompt() functions,
- enabling tests to simulate the actions of the user when these occur.
- Under normal condition, no visible JavaScript dialog-box will appear.
-
- If your application generates alerts, confirmations, or prompts, you
- *must* use assertAlert, assertConfirmation and assertPrompt (or their
- "verify" equivalents) to handle them. Any unhandled alerts will result
- in the test failing.
-
- *PROVISO:* Selenium is unable to handle alerts, confirmations, or
- prompts raised during processing of the 'onload' event. In such cases
- a visible dialog-box WILL appear, and Selenium will hang until you
- manually handle it. This is an unfortunate restriction, but at this
- time we have no solution.
-
-------------------------------------
-Parameter construction and Variables
-------------------------------------
-
- All Selenium command parameters can be constructed using both simple
- variable substitution as well as full JavaScript. Both of these
- mechanisms can access previously stored variables, but do so using
- different syntax.
-
- **Stored Variables**
-
- The commands *store*, *storeValue* and *storeText* can be used to store a variable
- value for later access. Internally, these variables are stored in a map called "storedVars",
- with values keyed by the variable name. These commands are documented in the command reference.
-
- **Variable substitution**
-
- Variable substitution provides a simple way to include a previously stored variable in a
- command parameter. This is a simple mechanism, by which the variable to substitute is indicated
- by ${variableName}. Multiple variables can be substituted, and intermixed with static text.
-
- Example:
-
- ========== ==================== ==========
- store Mr title
- storeValue nameField surname
- store ${title} ${surname} fullname
- type textElement Full name is: ${fullname}
- ========== ==================== ==========
-
- **JavaScript evaluation**
-
- JavaScript evaluation provides the full power of JavaScript in constructing a command parameter.
- To use this mechanism, the *entire* parameter value must be prefixed by
- 'javascript{' with a trailing '}'. The text inside the braces is evaluated as a JavaScript expression,
- and can access previously stored variables using the *storedVars* map detailed above.
- Note that variable substitution cannot be combined with JavaScript evaluation.
-
- Example:
-
- ========== ================================================ ==========
- store javascript{'merchant' + (new Date()).getTime()} merchantId
- type textElement javascript{storedVars['merchantId'].toUpperCase()}
- ========== ================================================ ==========
-
-------------------
-Extending Selenium
-------------------
-
- It can be quite simple to extend Selenium, adding your own actions, assertions and locator-strategies.
- This is done with JavaScript by adding methods to the Selenium object prototype, and the PageBot
- object prototype. On startup, Selenium will automatically look through methods on these prototypes,
- using name patterns to recognise which ones are actions, assertions and locators.
-
- The following examples try to give an indication of how Selenium can be extended with JavaScript.
-
-**Actions**
-
- All *doFoo* methods on the Selenium prototype are added as actions. For each action *foo* there
- is also an action *fooAndWait* registered. An action method can take up to 2 parameters, which
- will be passed the second and third column values in the test.
-
- Example: Add a "typeRepeated" action to Selenium, which types the text twice into a text box.
-
- ::
-
- Selenium.prototype.doTypeRepeated = function(locator, text) {
- // All locator-strategies are automatically handled by "findElement"
- var element = this.page().findElement(locator);
-
- // Create the text to type
- var valueToType = text + text;
-
- // Replace the element text with the new text
- this.page().replaceText(element, valueToType);
- };
-
-**Assertions**
-
- All *assertFoo* methods on the Selenium prototype are added as
- assertions. For each assertion *foo* there is an *assertFoo* and
- *verifyFoo* registered. An assert method can take up to 2 parameters,
- which will be passed the second and third column values in the test.
-
- Example: Add a *valueRepeated* assertion, that makes sure that the
- element value consists of the supplied text repeated. The 2 commands
- that would be available in tests would be *assertValueRepeated* and
- *verifyValueRepeated*.
-
- ::
-
- Selenium.prototype.assertValueRepeated = function(locator, text) {
- // All locator-strategies are automatically handled by "findElement"
- var element = this.page().findElement(locator);
-
- // Create the text to verify
- var expectedValue = text + text;
-
- // Get the actual element value
- var actualValue = element.value;
-
- // Make sure the actual value matches the expected
- Assert.matches(expectedValue, actualValue);
- };
-
-**Locator Strategies**
-
- All *locateElementByFoo* methods on the PageBot prototype are added as locator-strategies. A locator strategy takes 2 parameters, the first being the locator string (minus the prefix), and the second being the document in which to search.
-
- Example: Add a "valuerepeated=" locator, that finds the first element a value attribute equal to the the supplied value repeated.
-
- ::
-
- // The "inDocument" is a the document you are searching.
- PageBot.prototype.locateElementByValueRepeated = function(text, inDocument) {
- // Create the text to search for
- var expectedValue = text + text;
-
- // Loop through all elements, looking for ones that have
- // a value === our expected value
- var allElements = inDocument.getElementsByTagName("*");
- for (var i = 0; i < allElements.length; i++) {
- var testElement = allElements[i];
- if (testElement.value && testElement.value === expectedValue) {
- return testElement;
- }
- }
- return null;
- };
-
-**user-extensions.js**
-
- By default, Selenium looks for a file called "user-extensions.js", and loads the JavaScript code found in that file. This file provides a convenient location for adding features to Selenium, without needing to modify the core Selenium sources.
-
- In the standard distibution, this file does not exist. Users can create this file and place their extension code in this common location, removing the need to modify the Selenium sources, and hopefully assisting with the upgrade process.
-
-------------------
-
-:
diff --git a/tests/FunctionalTests/selenium/doc/testRunner.txt b/tests/FunctionalTests/selenium/doc/testRunner.txt
deleted file mode 100644
index 56b949d2..00000000
--- a/tests/FunctionalTests/selenium/doc/testRunner.txt
+++ /dev/null
@@ -1,99 +0,0 @@
-=========================
-TestRunner Reference
-=========================
------------
-Test Suites
------------
-
- A test suite is represented by an HTML document containing a single-column table. Each entry in the table should be a hyperlink to a test-case document. The first row will be ignored by Selenium, so this can be used for a title, and is typically used to hold a title.
-
- By default Selenium will attempt to load the test-suite from "tests/TestSuite.html". An alternative test-suite source can be specified by appending a "test" parameter to the TestRunner.html URL, e.g.::
-
- http://localhost:8000/TestRunner.html?test=AllTests.php
-
- The "test" URL is interpreted relative to the location of TestRunner.html.
-
-----------
-Test Cases
-----------
-
- A test-case is represented by an HTML document, containing a table with 3 columns: *command*, *target*, *value*. Not all commands take a value, however. In this case either leave the column blank or use a to make the table look better.
-
- The first row will be ignored by Selenium, so this can be used for a title or any other information.
-
- Example:
-
- ========== ============ ==========
- Simple Test Table
- --------------------------------------
- open /mypage
- type nameField John Smith
- click submitButton True
- verifyText name John Smith
- ========== ============ ==========
-
------------------
-SetUp / TearDown
------------------
-
- There are no setUp and tearDown commands in Selenium, but there is a way to handle these common testing operations. On the site being tested, create URLs for setUp and tearDown. Then, when the test runner opens these URLs, the server can do whatever setUp or tearDown is necessary.
-
- Example:
-
- For the T&E project, we wanted the functional tests to run as a dummy user. Therefore, we made a /setUpFT URL that would create a dummy user and write the userID to the page. Then, we can store this value (using the command storeValue) and use it in the script. Finally, we made a /tearDownFT URL which takes the dummy userID as a parameter and deletes the user. Therefore, our tests look like this:
-
- ========== ============================ ==========
- Setup and Teardown
- ------------------------------------------------------
- open /setUpFT
- storeValue userid
- open /login
- type userID ${userid}
- click submit
- open /tearDownFT?userid=${userid}
- ========== ============================ ==========
-
-
-----------------------
-Continuous Integration
-----------------------
-
- Selenium can be integrated with an automated build. When the parameter "auto=true" is added to the URL, Selenium will run the entire suite of tests, and then post the results to a handling URL. The default URL is "/postResults", but an alternative handler location can be provided by specifying a "resultsUrl" parameter.
-
- The fields of the post are:
-
- ================== ======================================================================================================
- Parameter Description
- ================== ======================================================================================================
- result the word "passed" or "failed" depending on whether the whole suite passed or at least one test failed.
- totalTime the time in seconds for the whole suite to run
- numTestPasses tht total number of tests which passed
- numTestFailures the total number of tests which failed.
- numCommandPasses the total number of commands which passed.
- numCommandFailures the total number of commands which failed.
- numCommandErrors the total number of commands which errored.
- suite the suite table, including the hidden column of test results
- testTable.1 the first test table
- testTable.2 the second test table
- ... ...
- testTable.N The Nth test table
- ================== ======================================================================================================
-
- Therefore, the steps for continuous integration are:
- 1. Create a servlet-type application at the url /postResults which can read the parameters above and write them to a file
- 2. Create a script which can start up a brower and send to to the URL: selenium?auto=true
- - Generally, this can be done by merely calling the browser with the URL as an argument:
- firefox.exe http://localhost/selenium?auto=true
- 3. Make your continuous build:
- - Call the script from step 2, preferably using more than one browser
- - Wait for it to finish, possibly by checking for the existence of the file(s) from step 1
- - Parse these files to determine whether the build passed or failed
- - Act accordingly (send emails, update a build web page, etc.)
-
-
-------------------
-
-:Authors: Paul Gross, Jason Huggins
-:Created Date: 08/23/2004
-:Modified Date: 28/01/2005
-:Created With: reStructuredText: http://docutils.sourceforge.net/rst.html
diff --git a/tests/FunctionalTests/selenium/doc/testrunner.html b/tests/FunctionalTests/selenium/doc/testrunner.html
deleted file mode 100644
index 86cac0cb..00000000
--- a/tests/FunctionalTests/selenium/doc/testrunner.html
+++ /dev/null
@@ -1,213 +0,0 @@
-
-
-
-
-
-
-TestRunner Reference
-
-
-
-
A test suite is represented by an HTML document containing a single-column table. Each entry in the table should be a hyperlink to a test-case document. The first row will be ignored by Selenium, so this can be used for a title, and is typically used to hold a title.
-
By default Selenium will attempt to load the test-suite from "tests/TestSuite.html". An alternative test-suite source can be specified by appending a "test" parameter to the TestRunner.html URL, e.g.:
A test-case is represented by an HTML document, containing a table with 3 columns: command, target, value. Not all commands take a value, however. In this case either leave the column blank or use a to make the table look better.
-
The first row will be ignored by Selenium, so this can be used for a title or any other information.
There are no setUp and tearDown commands in Selenium, but there is a way to handle these common testing operations. On the site being tested, create URLs for setUp and tearDown. Then, when the test runner opens these URLs, the server can do whatever setUp or tearDown is necessary.
-
Example:
-
-
For the T&E project, we wanted the functional tests to run as a dummy user. Therefore, we made a /setUpFT URL that would create a dummy user and write the userID to the page. Then, we can store this value (using the command storeValue) and use it in the script. Finally, we made a /tearDownFT URL which takes the dummy userID as a parameter and deletes the user. Therefore, our tests look like this:
Selenium can be integrated with an automated build. When the parameter "auto=true" is added to the URL, Selenium will run the entire suite of tests, and then post the results to a handling URL. The default URL is "/postResults", but an alternative handler location can be provided by specifying a "resultsUrl" parameter.
-
The fields of the post are:
-
-
-
-
-
-
-
-
Parameter
-
Description
-
-
-
-
result
-
the word "passed" or "failed" depending on whether the whole suite passed or at least one test failed.
-
-
totalTime
-
the time in seconds for the whole suite to run
-
-
numTestPasses
-
tht total number of tests which passed
-
-
numTestFailures
-
the total number of tests which failed.
-
-
numCommandPasses
-
the total number of commands which passed.
-
-
numCommandFailures
-
the total number of commands which failed.
-
-
numCommandErrors
-
the total number of commands which errored.
-
-
suite
-
the suite table, including the hidden column of test results
-
-
testTable.1
-
the first test table
-
-
testTable.2
-
the second test table
-
-
...
-
...
-
-
testTable.N
-
The Nth test table
-
-
-
-
-
-
Therefore, the steps for continuous integration are:
-
-
Create a servlet-type application at the url /postResults which can read the parameters above and write them to a file
-
-
-
Create a script which can start up a brower and send to to the URL: selenium?auto=true
-
-
-
Generally, this can be done by merely calling the browser with the URL as an argument:
-Broadly speaking there are two modes of operation for Selenium
-TestRunner and Driven
-
TestRunner
-
-
-The TestRunner mode of operation for Selenium is where its HTML &
-Javascript
-and the test suite are deployed alongside the Application Under Test
-(AUT) on a arbitrary web server. The test suite is coded as tables in a
-HTML page for each test.
-
-See test runner documentation for more
-information.
-
Driven
-
-Driven Selenium is where the browser is under the the control of a
-process on the same machine. That process is either a Java, .Net, Ruby
-or Python
-application and it is typically run in conjunction with a unit testing
-framework like JUnit or NUnit. Also possible, is a console application
-driving a browser interactively.
-
-The test script is one that would be recognisable to people adept with
-unit test frameworks :
-
- public void testOKClick() {
- selenium.verifyTitle("First Page");
- selenium.open("/TestPage.html");
- selenium.click("OKButton");
- selenium.verifyTitle("Another Page");
- }
-
-The difference from normal unit testing is that as part of the startup,
-three major things have to happen:
-
-
The test framework needs to publish a fresh copy of the AUT.
-Selenium prefers to mount its own web server temporarily for the
-purposes of testing.
-
The test framework needs to publish the static Selenium's HTML
-pages and Javascript in an apparent directory
-on the same web server as (1).
-
The test framework needs to open a browser instance and point it
-to Selenium.html served in (2) above.
-
-As each of these is a fairly time consuming operation, it is best that
-all three of those happen in a one-time setup mode. As such, and
-even though these leverage a unit testing framework, this is definately
-for acceptance or functional rather than unit-testing.
-
-Some variations in the accesibility of the the webserver in question
-for testing purposes or its scriptablity mean a more complex setup is
-required:
-
-
-
-See the driven documentation for more
-information.
-
-
