diff options
Diffstat (limited to 'tests/FunctionalTests/selenium/doc/driven.html')
| -rw-r--r-- | tests/FunctionalTests/selenium/doc/driven.html | 206 |
1 files changed, 0 insertions, 206 deletions
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 @@ -<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> -<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> -<head> - <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> - <meta name="generator" - content="Docutils 0.3.6: http://docutils.sourceforge.net/"> - <title>Driven Selenium Reference</title> - <link rel="stylesheet" href="default.css" type="text/css"> -</head> -<body> -<div class="document" id="selenium-reference"> -<div class="section" id="test-tables"> -<h2><a name="test-tables"></a>Overview</h2> -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.<br> -<h2>Selenium & Selenese</h2> -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 <a - href="http://www.mozilla.org/projects/security/components/same-origin.html">http://www.mozilla.org/projects/security/components/same-origin.html</a> -for more info.<br> -<br> -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. - <br> -<br> - | open | /foo/bar.html | |<br> -<br> -We refer to this architecture are reply/request rather than the more -ususal request/reply.<br> -<h2><a name="test-tables">Sample test method<br> -</a></h2> -The test script is one that would be recognisable to people adept with -unit test frameworks :<br> -<br> -For Java -<br> -<br> - public void testOKClick() {<br> - selenium.verifyTitle("First Page");<br> - selenium.open("/TestPage.html");<br> - selenium.click("OKButton");<br> - selenium.verifyTitle("Another Page");<br> - }<br> -<br> -The difference from normal unit testing is that as part of the startup, -three major things have to happen:<br> -<ol> - <li>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.</li> - <li>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).</li> - <li>The test framework needs to open a browser instance and point it -to Selenium.html served in (2) above.</li> -</ol> -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.<br> -<h2>Example Setup<br> -</h2> -</div> -<div class="section" id="continuous-integration">For Java -<br> -<br> - selenium = new DefaultSelenium("c:\foo\bar-web-app\");<br> -<br> -The above will instantiate a web server using <a - href="http://jetty.mortbay.com/jetty/index.html">Jetty</a>, 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.<br> -<br> -The above would ususally be done in a setup method if under unit test -control. See <a - href="http://junit.sourceforge.net/doc/faq/faq.htm#organize_3">http://junit.sourceforge.net/doc/faq/faq.htm#organize_3</a> -for advice on one time setup for Java.<br> - <br> -A more complex case could be -<br> -<br> - selenium = new DefaultSelenium(new -TomcatCommandProcessor("c:\foo\bar-web-app"), new -MyOperaBrowserLauncher()), <br> -<h2>Command Reference</h2> - void chooseCancelOnNextConfirmation();<br> - void click(String field);<br> - void clickAndWait(String field);<br> - void open(String path);<br> - void pause(int duration);<br> - void selectAndWait(String field, String value);<br> - void selectWindow(String window);<br> - void setTextField(String field, String value);<br> - void storeText(String element, String value);<br> - void storeValue(String field, String value);<br> - void testComplete();<br> - void type(String field, String value);<br> - void typeAndWait(String field, String value);<br> - void verifyAlert(String alert);<br> - void verifyAttribute(String element, String value);<br> - void verifyConfirmation(String confirmation);<br> - void verifyElementNotPresent(String type);<br> - void verifyElementPresent(String type);<br> - void verifyLocation(String location);<br> - void verifySelectOptions(String field, String[] -values);<br> - void verifySelected(String field, String value);<br> - void verifyTable(String table, String value);<br> - void verifyText(String type, String text);<br> - void verifyTextPresent(String type, String text);<br> - void verifyTitle(String title);<br> - void verifyValue(String field, String value);<br> -<h2>Deployment Choices</h2> -<h3>Embedded Web Server</h3> -<p> -<img alt="Picture of Browser and Driving process" src="images/Embedded.png" - style="width: 518px; height: 302px;" align="top"><br> -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 <a - href="http://jetty.mortbay.com/jetty/index.html">Jetty</a> or <a - href="http://jakarta.apache.org/tomcat/">Tomcat</a>. <br> -<br> -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. <br> -</p> -<p style="color: rgb(255, 0, 0);">[ For release 0.2 - this is the only -mode that really works. Those below will be fine for 0.3 and above ]<br> -</p> -<h3>Adjacent Web Server</h3> -<img alt="diagram of adjacent config" src="images/Adjacent.png" - style="width: 534px; height: 572px;"><br> -By adjacent we mean a process on the same machine as the driver. As -such it would appear as localhost to browsers. <br> -<br> -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. <br> -<br> -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.<br> -<span style="font-weight: bold;"><br> -Selenese-proxy</span><br style="font-weight: bold;"> -<br> -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).<br> -<h3>Nearby Web Server <br> -</h3> -This is where the AUT is running on a nearby testing stack or dedicated -development box (not the developer's own workstation).<br> -<br> -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.<span style="font-weight: bold;"><br> -</span> -<h3>Remote Web Server <br> -</h3> -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.<br> -<span style="font-weight: bold;"><br> -Funnel</span><br style="font-weight: bold;"> -<br> -We are writing an application called the funnel that can help us -overcome the <a - href="http://www.mozilla.org/projects/security/components/same-origin.html">same -origin</a> 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.<br> -<br> -<br> -</div> -</div> -</body> -</html> |