-
-
-
-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.
-Sample test method
-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:
-
-Example Setup
-
-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.
-
Sample test method
-
-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. -
-
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()),
-
- void click(String field);
- void clickAndWait(String field);
- void open(String path);
- void pause(int duration);
- void selectAndWait(String field, String value);
- void selectWindow(String window);
- void setTextField(String field, String value);
- void storeText(String element, String value);
- void storeValue(String field, String value);
- void testComplete();
- void type(String field, String value);
- void typeAndWait(String field, String value);
- void verifyAlert(String alert);
- void verifyAttribute(String element, String value);
- void verifyConfirmation(String confirmation);
- void verifyElementNotPresent(String type);
- void verifyElementPresent(String type);
- void verifyLocation(String location);
- void verifySelectOptions(String field, String[] -values);
- void verifySelected(String field, String value);
- void verifyTable(String table, String value);
- void verifyText(String type, String text);
- void verifyTextPresent(String type, String text);
- void verifyTitle(String title);
- void verifyValue(String field, String value);
-
-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 = 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()),
-
Command Reference
- void chooseCancelOnNextConfirmation();- void click(String field);
- void clickAndWait(String field);
- void open(String path);
- void pause(int duration);
- void selectAndWait(String field, String value);
- void selectWindow(String window);
- void setTextField(String field, String value);
- void storeText(String element, String value);
- void storeValue(String field, String value);
- void testComplete();
- void type(String field, String value);
- void typeAndWait(String field, String value);
- void verifyAlert(String alert);
- void verifyAttribute(String element, String value);
- void verifyConfirmation(String confirmation);
- void verifyElementNotPresent(String type);
- void verifyElementPresent(String type);
- void verifyLocation(String location);
- void verifySelectOptions(String field, String[] -values);
- void verifySelected(String field, String value);
- void verifyTable(String table, String value);
- void verifyText(String type, String text);
- void verifyTextPresent(String type, String text);
- void verifyTitle(String title);
- void verifyValue(String field, String value);
-
Deployment Choices
-Embedded Web Server
-
-
-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.
-
-
-