summaryrefslogtreecommitdiff
path: root/tests/FunctionalTests/selenium/doc/developingdrivers.html
diff options
context:
space:
mode:
Diffstat (limited to 'tests/FunctionalTests/selenium/doc/developingdrivers.html')
-rw-r--r--tests/FunctionalTests/selenium/doc/developingdrivers.html134
1 files changed, 134 insertions, 0 deletions
diff --git a/tests/FunctionalTests/selenium/doc/developingdrivers.html b/tests/FunctionalTests/selenium/doc/developingdrivers.html
new file mode 100644
index 00000000..4c2594d9
--- /dev/null
+++ b/tests/FunctionalTests/selenium/doc/developingdrivers.html
@@ -0,0 +1,134 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+<html>
+<head>
+ <meta content="text/html; charset=ISO-8859-1"
+ http-equiv="content-type">
+ <title>Developing Drivers</title>
+</head>
+<body>
+<h2>Overview</h2>
+This page details important information for people developing drivers
+for Selenium.<br>
+<h2>Same Origin Policy</h2>
+This is a security issue that affects all modern browsers. It is well
+described <a
+ href="http://www.mozilla.org/projects/security/components/same-origin.html">here</a>,
+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.<br>
+<h2>The Driver</h2>
+The driver has a number of duties. These are typically.. <br>
+<ul>
+ <li>Instantiating the web server with a dynamic app (servlets for
+Java) </li>
+ <li>Launching a browser with a with a URL that makes sense for
+connecting to that server </li>
+ <li>providing an API to such that commands can be routed though the
+dynamic app to the browser</li>
+</ul>
+<h2>Local, Remote and URLs<br>
+</h2>
+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.&nbsp; <br>
+<br>
+Thus, an application as deployed ...<br>
+<br>
+<img alt="http://localhost:8080/" src="images/stockmeister.png"
+ style="width: 361px; height: 68px;"><br>
+<br>
+... would appear like so for the purposes of testing ...<br>
+<br>
+<img alt="http://localhost:8080/" src="images/localhostAut.png"
+ style="width: 346px; height: 43px;"><br>
+<br>
+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 ...<br>
+<br>
+<img alt="http://localhost:8080/selenium/"
+ src="images/localhostSelenium.png"
+ style="width: 326px; height: 57px;"><br>
+<br>
+The dynamic webapp needs to be similarly mounted ...<br>
+<br>
+<img alt="http://localhost:8080/selenium/driver?..."
+ src="images/localhostDriver.png" style="width: 318px; height: 52px;"><br>
+<br>
+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.&nbsp; This is easier in some languages and web servers than
+others.&nbsp; Also full programatic start/stop control over the web
+server is not always possible for some larger web servers
+implementations.<br>
+<h2>Reply/Request Architecture</h2>
+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.&nbsp; 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.&nbsp; The results from the <span style="font-style: italic;">previous</span>
+command go back as query string parameters, and the <span
+ style="font-style: italic;">next</span> command is communicated in a
+text/plain document<br>
+<br>
+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.&nbsp; Java, until 1.5, did not have a blocking
+queue to make this easy. Most other languages did.<br>
+<h2><span style="font-weight: bold;">Selenese</span></h2>
+<table style="width: 100%;" border="1" cellpadding="2" cellspacing="2">
+ <tbody>
+ <tr>
+ <td>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. <br>
+ <br>
+Responses come from the browser to the driver in a query
+string like&nbsp;&nbsp; <br>
+ <br>
+&nbsp; <span style="font-family: monospace;">commandResult=OK</span>, <br>
+ <br>
+Commands go from the driver to the
+browser-bot in a text/plain document:<br>
+ <br>
+&nbsp; <span style="font-family: monospace;">| open | /foo/bar.html | |</span><br
+ style="font-family: monospace;">
+ <br>
+This two way communication is of course invisible to the observer.</td>
+ <td style="width: 30%; background-color: rgb(255, 153, 102);">The
+BrowserBot, by understanding Selenese, allows a process other than the
+browser itsself to direct events on the Application Under Test.&nbsp; <br>
+ <br>
+The Selenese language is simple enough to be commandable by any
+language that has an API that can handle HTTP requests. <br>
+ <br>
+Thus, Selenese allows many different open, free or closed license
+drivers to interoperate with the BrowserBot.</td>
+ </tr>
+ </tbody>
+</table>
+<h2>Choregraphy</h2>
+The driver cleary has some fairly heavy things to do.&nbsp; 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.&nbsp; It is appropriate for wait timeouts to be
+generous here.&nbsp; 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).&nbsp; 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.&nbsp; 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.<br>
+<br>
+<br>
+</body>
+</html>