diff options
Diffstat (limited to 'tests/FunctionalTests/selenium/doc/driven.html')
| -rw-r--r-- | tests/FunctionalTests/selenium/doc/driven.html | 206 |
1 files changed, 206 insertions, 0 deletions
diff --git a/tests/FunctionalTests/selenium/doc/driven.html b/tests/FunctionalTests/selenium/doc/driven.html new file mode 100644 index 00000000..a5f33dff --- /dev/null +++ b/tests/FunctionalTests/selenium/doc/driven.html @@ -0,0 +1,206 @@ +<!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> |